#1 Burning Software

In prior SDK versions I was unable to use StarBurn_ISO9660JolietFileTree_AddMemory() because the method truncated the input filename to 8.3 characters. My workaround was to write the memory buffer to disk and then use StarBurn_ISO9660JolietFileTree_Add().

In the 6.4.10 SDK release the 8.3 filename restriction was resolved so I am attempting to use the AddMemory() version again. Initially everything looked good -- the memory buffer was correctly written out to the disc and had the complete, long filename attached. However I noticed that nother small file I wrote out during the same session using the file-based Add() was corrupted - random garbage.

I verified that the source file that got corrupted was good. I also experimented switching back and forth between Add() (old workaround technique) and AddMemory() and verified that the corruption issue only happens when AddMemory() is called. I debugged into my code to verify that the size and other parameters being input into AddMemory() looked good.

It's very odd that it's not the file created by AddMemory() that is corrupted, but another file created through Add() that gets hit. The code for that other file creation is identical regardless of how I add my large memory buffer to the session.

The general sequence of commands is:

StarBurn_ISO9660JolietFileTree_Add(small file 1) ** corrupted on disc**
StarBurn_ISO9660JolietFileTree_Add(small file 2)StarBurn_ISO9660JolietFileTree_AddMemory(big memory buffer)
StarBurn_ISO9660JolietFileTree_BuildImage
StarBurn_CdvdBurnerGrabber_TrackAtOnceFromTree
StarBurn_CdvdBurnerGrabber_CloseSession

Final note...the "small file 1" above that gets corrupted is a file that previously existed in clear, uncorrupted form and is getting updated with new information. This has never been a problem previously but probably worth mentioning.

I will attach the debug log below.

-Chris