#1 Burning Software

I am using the ISO9660JolietFileTree_Add method to add files from my hard drive. This is working as expected.

I am also using the ISO9660JolietFileTree_AddMemory method (in exactly the same session as the Add() method above) to insert blocks of memory directly into my Joliet tree (not ISO9660 format...selected FILE_TREE_JOLIET).

All indications are that both files are successfully burned to disc, and indeed I can go back and see both files in Windows Explorer. I can even open both files and the contents are correct.

The problem is that the file I added from memory seems to have a corrupted (truncated) filename. I am setting the p__PCHAR__Name parameter in AddMemory() to something like "200601121455572.tar". The resulting filename on the disc is "200601121455". The remaining "572.tar" has been lost.

When I import the track for subsequent write operations, I get the following callback trace for that tar file:

Callback(): Adding name 'ImportingTrack( 1 ):/200601121455, tree node(s) 193

I then go to add a new file called "200601121455573.tar" also with AddMemory, and here is the callback trace for that:

Callback(): Adding name '', tree node(s) 196

...and finally, when I destroy the tree the callback shows the removal of the new filename as:
Callback(): Removing name '', tree node(s) 1

I am using the Callback tracing as shown in the TrackAtOnceFromTreeWithImport sample code.

I am assuming that the p__PCHAR__Name parameter to AddMemory is supposed to be the resulting filename on disc. So, assuming I am using the AddMemory method correctly (always suspect on my part!), there seem to be two problems:

1. p__PVOID__CallbackSpecial1 parameter in the callback method does not contain the p__PCHAR__Name parameter from the original AddMemory() call...it is blank.

2. Filenames provided in p__PCHAR__Name to AddMemory() are truncated at 12 characters when burned to disc. Is this some sort of 8.3 (=12 chars) limitation? My other files added through the Add() method also have > 12 chars and show up fine on disc.

I have tried burning shorter names from memory like "2006.tar" and those names are not truncated on disc (through they still appear as blank in the p__PVOID__CallbackSpecial1 parameter.

If needed I can provide debug logs but this looks like simple user error or simple-to-reproduce bug.

Thanks,
Chris

Chris, can you provide me with a source code for calling AddMemory(...)?
Just to be sure you're doing everything correctly

And I'll check again, maybe there's indeed some sort of 8.3 name limitation.

Thanks!

Just emailed you the relevant portions of my source code, thanks!

-Chris

Checking e-mail. Would reply you there. Thanks!

Just duplicating the answer here as it may be in use by others

Chris,

OK, I've verified the source code and looks like both things work correctly.

1) Memory files are truncated to DOS 8.3 format

2) When callback reports it does touch non-existing true file name path for memory file (as it's content comes from memory and not from the disk). That's why path in the callback is void.

Would you like this things just be covered in the documentation (actually I've just did it) or would you like some mark (say *MEMORY* string in the callback file name or whatever) to be found in the memory mapped file?

Please let us know

Thanks!

Thanks Anton.

1) I'm not sure from your response...presumably the 8.3 limitation is considered a bug that you will fix in the SDK? Otherwise the method is useless for long filenames. My workaround in QA right now is to write the 100MB memory blob to a temp file, Add() the temp file, then delete it. That'll pass functional testing but will slow the machine to a crawl in high-performance scenarios (our product is very disk-intensive, so we need to minimize the disk I/O).

2) I am not currently relying on the missing buffer name in the callback for any product features, I just noted it as an interesting fact in the truncation scenario. As far as what *should* happen from a general usability standpoint, I would think that the callback should contain the buffer name that was passed into the AddMemory() method. Is there any reason why the buffer name from AddMemory() can't be used as-is for both the eventual long filename and the callback parameter?

Regards,
Chris

1) No, DOS 8.3 name truncation was done from the very beginning. If it does not work for you (you need long names for memory files) we'll have to re-write this code.

2) Callbacks use FULL names (including path) so users can parse it. For memory located files we can do say <MEMORY>\<file name you've created> self-constructed path. If you need it.

What's the difference between passing AddMemory() a memory buffer with a long filename, and passing Add() a long filename representing a buffer on disk? Aren't both long names stored in the virtual Joliet tree and then propagated to the image in the same manner?

I you say "re-write" then obviously you know best , I'm just surprised that there is a big difference or why originally the target filenames were limited to 8.3 if the source was a buffer in memory yet buffers read from disk could have longer names...

At this point I don't know if a SDK change will be absolutely required before we can ship the product...we won't get to the high-performance testing for a while in QA. I would ask that the change get put on your to-do list somewhere, so that by the time we may need the change it's in the pipeline somewhere.

Thanks!

Originally we'd supported only disk-based files, memory mapped and pipes were added later (injected). So the way is not very stright forward and there are differences in the functionality.

I'm not sure why you mix "high performance ... " and short file names

OK, so I've added such a modifcations to StarBurn:

1) Now memory located files can have long names (> 8.3 DOS format).

2) Now callback would pass long file name instead of NULL if complete path does not exist (always true for memory located files and pipes)

If you'd like to get update before official release - please let me know. Thanks!

Hi Anton,

Just confirming this fix is in the recent 6.4.10 release?

Thanks,
Chris

Yes!