Rocket Division Software

Introduction:
When I add a file via Starburn_UDF2_FileUnicodeCreate w/o calling StarBurn_UDF2_FileDirectoryDateTimeSet after (on the just added file), I get a failure on accessing the file later.

Suspicion (based on empirical testing):
The Starburn_UDF2_FileUnicodeCreate by itself fails to initialize a file object completely, but calling the StarBurn_UDF2_FileDirectoryDateTimeSet seems to fix the problem.

Details:
I used the UDF2BuildBurn.c (ie StarBurn_UDF2_DirectoryUnicodeProcessEx) example to burn a directory with 1 mpeg-2 file in it. On reviewing of the just burned disc, everything always works. I created a clone of the UDF2BuildBurn.c to UDF2FiletreeBurn.c, and I replaced the StarBurn_UDF2_DirectoryUnicodeProcessEx call with a StarBurn_UDF2_DirectoryUnicodeCreate & StarBurn_UDF2_FileUnicodeCreate. So the UDF2FiletreeBurn.c basically creates the same directory as before, but only adds 1 file to the just created directory.
I used the same data for both tests, and both udf discs look identical. However, when I try to access the video file from the UDF2FiletreeBurn burn, I get a failure. When I access the same video file from the UDF2BuildBurn burn, everything works.
I looked at the debug output from the UDF2BuildBurn (ie StarBurn_UDF2_DirectoryUnicodeProcessEx) and noticed that a StarBurn_UDF2_FileDirectoryDateTimeSet call is being made for every directory/file being added. So I modified the UDF2FiletreeBurn to also do a StarBurn_UDF2_FileDirectoryDateTimeSet for both the StarBurn_UDF2_DirectoryUnicodeCreate & StarBurn_UDF2_FileUnicodeCreate, and now the resulting burn always works.
I am going to modify my code to use the StarBurn_UDF2_FileDirectoryDateTimeSet which fixes my problems, however I figured you might want to know about this oddity.

Of course we'd initially love to see you logs. Also I'm not sure what do you mean by "have problems accessing". Do you mean from Window explorer? What UDF version do you set and what OS are you playing with?

Here is the log of the failing media. We are using Windows XP, and I set the version to STARBURN_UDF_OS_CLASS_WINDOWS_NT. I'm using a custom mfc application that relies on a Matrox sdk to load and playback the mpeg-2 video. The application fails on GetFileInformation with a MV_E_FILE_FORMAT_NOT_SUPPORTED and the matching comment is: "The file info is unknown to matrox file reader (eg: a txt file); the file information could not be retried on this file. The file info structure is invalid and should not be used. This file can not be played."

This seems to be an issue with your Matrox code as they don't like UDF timestamps we set (but they are definitely OK as we pass UDF Verifier with ZERO errors). OK, I'll check what's the difference between set and unset timestamps and you can use IsGlobalDateTime set to TRUE for now.

BTW, I guess you can copy recorded file from the UDF disc w/o any problem and it's only Matrox code which fails, right?

OK, I've changed SDK in the way it will use default non-zero date and time for the files. You can drop a message to to see if it's gonna fix your issue. I still cannot trace it as everything works just fine here with all the verifiers...

You are correct. All the files can be copied off of the UDF disc w/o any problems (and Matrox will not fail when accessing the copies), and only the Matrox code fails (when accessing the file directly off the UDF disc). Thank you for the changes, and I'll contact support to get a copy of the changed SDK.

Please keep us updated so we could merge applied changes with the stable branch we're gonna publish very soon.