Imgburn not always preserving file date stamps

[rastan]

Hi,

 

I'm not sure whether this is a bug or a "feature". However, it's causing me a lot of problems.

 

I need to preserve all the file date stamps including the creation dates, so I'm creating my ISOs using the latest UDF format.

 

If the file creation date is earlier than the last modified date then the creation date is preserved as one would expect. However, if the creation date is later than the last modified date, then it becomes the same as the last modified date.

 

Can someone confirm whether this is a bug, or whether there's some obscure setting that I need to change to ensure that the creation date is always preserved.

 

Thanks in advance.

[LIGHTNING UK!]

The creation date can only be saved in the UDF v2.00+ file system. None of the others have a field for it, they only have fields for the access/modified/attribute dates.

[rastan]

The creation date can only be saved in the UDF v2.00+ file system. None of the others have a field for it, the only have fields for the access/modified/attribute dates.

 

Thanks for your reply.

 

I'm using UDF 2.60 in conjunction with ISO9660 and Joliet.

 

The thing is, the creation date is preserved only when it's earlier than the modification date. If I was using the wrong format then I'd assume that the creation date would never be preserved.

[LIGHTNING UK!]

I'm using UDF 2.60 in conjunction with ISO9660 and Joliet.

 

I need to preserve all the file date stamps including the creation dates, so I'm creating my ISOs using the latest UDF format

 

Doh, I really should read things more carefully.

 

Of course 'latest UDF format' doesn't mean anything because 'latest' can always change!

 

So anyway....

 

Ecma-167 says the following:

 

14.9.12 Access Date and Time (BP 72)

This field shall specify the most recent date and time of the day of file creation or read access to the file prior to

recording this File Entry. This date and time shall not be earlier than the File Creation Date and Time specified in

the File Times Extended Attribute, if any.

 

14.9.13 Modification Date and Time (BP 84)

This field shall specify the most recent date and time of the day of file creation or write access to the file. This

date and time shall not be earlier than the File Creation Date and Time specified in the File Times Extended

Attribute, if any.

 

14.9.14 Attribute Date and Time (BP 96)

This field shall specify the most recent date and time of the day of file creation or modification of the attributes of

the file. This date and time shall not be earlier than the File Creation Date and Time specified in the File Times

Extended Attribute, if any.

 

So basically, rather than adjusting the Access/Modified/Attribute times to ensure none of them are before the creation time, I adjust the creation time to ensure it's never after them.

 

After all, Explorer shows the Modified date by default, not the creation date. So, for visual inspection/verification of things, it's probably more important that it matches the file on the hdd rather than the Creation date.

 

It would be trivial to add an option to skip the bit of code that does what you're seeing.

[rastan]

It would be trivial to add an option to skip the bit of code that does what you're seeing.

 

OK, so it is intentional behaviour. Thanks for clarifying that.

 

I would be very grateful of you could provide an option to always preserve the creation date.

 

I should perhaps explain why I need both the creation and modification dates to be preserved. Well you can blame Microsoft for that. Their applications and utilities have a very cavalier and inconsistent approach to timestamps when copying files. Some preserve the creation date and some preserve the modification date but very few preserve both. So I've ended up with a situation where some of my files have a correct modification date and others have a correct creation date. Unfortunately, I haven't got the time to go through all my files manually correcting the dates (do you know of any utilities that can do this?) so for now I'm preserving both dates and hoping that at least one of them is correct.

 

Also, from a philosophical perspective, I believe that, by default, any copying or archiving programs should preserve as much information as possible (including the timestamps). It's amazing how few programs in both the Windows and Linux/Unix world actually behave in that way.

 

Fixing creation dates that appear to be wrong (i.e. they're after the modification date) is potentially useful but I don't think it should be the default behaviour. Come to think of it, it might also be useful to provide an option to set both the creation and modification dates to whichever date is the earliest of the two. That would fix the problem that I've encountered.

[LIGHTNING UK!]

If you move a file then all dates will be preserved.

 

If you copy a file then it gets a new creation date, the rest are preserved.

 

The Philips UDF verifier throws up a warning for files with a creation date before the modified/access date, I'm sure that was probably why I added the code to adjust it in the first place.

 

i.e.

 

324 read block

EFE file type FILE UniqueID: #0000000000000010 name: "Test Dates.txt"

EFE 92 Warning: Creation Time should not be later than

- Modification Time, DCN-5153, ECMA 4/14.9.13, UDF 3.3.4.3.1, UDF 3.1.1.

- Creation Time: 2010-05-02 11:15:08 +01:00

- Modification Time: 2010-04-04 19:04:07 +01:00

- name: "Test Dates.txt"

EFE 116 Warning: Creation Time should not be later than

- Attribute Time, DCN-5153, ECMA 4/14.9.14, UDF 3.3.4.3.1, UDF 3.1.1.

- Creation Time: 2010-05-02 11:15:08 +01:00

- Attribute Time: 2010-04-04 19:04:07 +01:00

- name: "Test Dates.txt"

cnt: extent type, size, location,part, body, total alloc

1: long_ad 0 4525328 64 0 4525328 4526080

EFE 216 Verify embedded EA Space, 24 bytes

EAHD name: "Test Dates.txt"

 

I will add an option to disable the compliance modification so the file's true 'creation' date/time will be used.

[rastan]

I will add an option to disable the compliance modification so the file's true 'creation' date/time will be used.

 

Thanks. That would be great.

 

I've been reading about the way that Windows handles file timestamps and have come across a potential problem. I'm not sure whether it's relevant to Imgburn but thought it might be worth mentioning anyway.

 

Apparently, the NTFS filesystem stores filestamps in Universal Coordinated Time (UTC). This is more or less the same as Greenwich Mean Time (GMT) and means that the timestamps are independent of the time zone and whether daylight saving adjustments are in force.

 

However, for historical reasons, FAT16/32 timestamps are stored in local time. That's fine until you need to copy files from a FAT partition to an NTFS one, or vice versa.

 

The problem is that Windows doesn't do the conversion properly. This is best illustrated by an example.

 

Supposing you've got a file created in December (in the UK) sitting on a FAT32 partition and you decide to copy it to an NTFS partition. Windows will convert the timestamp from local time to UTC but it bases the conversion on the local time system currently in force, not the one that applied on the date that the file was actually created.

 

If the file is copied in December then the conversion will be done from GMT to UTC. However, if the file is copied in June then the conversion will be done from British Summer Time (i.e. GMT+1) to UTC.

 

In my opinion this is wrong. In both cases, the conversion should be from GMT to UTC because in December (in the UK) time is measured by GMT.

[ilitws]

@LIGHTNING UK! Thanks for providing useful learning as always. As a result of all this my understanding of how to use ImgBurn 2.5.1 keeps improving. An important learning has been that in settings choosing the latest updated version is not the same thing as what we generally understand version update to mean. In ImgBurn, in settings, each version has a defined functionality suited to a specific situation & so in that sense a version update in settings in ImgBurn is not the same as what comes to our mind when someone says version update @rastan I recommend you download & read entirely The ImgBurn Functions.pdf A member suggested this to me as I am a newbie, excellent advice, I did so & benefited enormously & so suggest you do the same The software for changing file creation & file modification date is FileMenu Tools 5.8. It's the best

[rastan]

Hi LIGHTNING UK,

 

I'm wondering whether this problem was ever fixed. Can you give me an update.

 

Thanks.

[LIGHTNING UK!]

Yup, via a new checkbox called 'Allow Non-Compliant File Creation Dates' on the Advanced -> Restrictions -> UDF tab.

[rastan]

Yup, via a new checkbox called 'Allow Non-Compliant File Creation Dates' on the Advanced -> Restrictions -> UDF tab.

 

Thanks. I'll check it out.

 

Can you tell me whether the time stamps are stored in local time (which is what FAT uses) or UTC (which is what NTFS uses)?

[rastan]

Yup, via a new checkbox called 'Allow Non-Compliant File Creation Dates' on the Advanced -> Restrictions -> UDF tab.

 

I've just downloaded version 2.5.1.0 from the ImgBurn mirror site. Unfortunately, the checkbox you refer to seems to be missing.

[LIGHTNING UK!]

From the UDF 1.02 docs

 

All timestamps shall be recorded in local time. Time

zones shall be recorded on operating systems that

support the concept of a time zone.

 

The option is new for v2.5.2.0 - and it's not out yet.

[rastan]

From the UDF 1.02 docs

 

All timestamps shall be recorded in local time. Time

zones shall be recorded on operating systems that

support the concept of a time zone.

 

The option is new for v2.5.2.0 - and it's not out yet.

 

That's interesting. Is this a global or a per file setting i.e. will all files on the ISO have to be treated in the same way, or will ImgBurn differentiate between files coped from a FAT partition and those copied from a NTFS partition?

[LIGHTNING UK!]

It's for any time a timestamp is recorded in the file system descriptors.

 

Even if they're stored differently in FAT and NTFS, surely you still see the same time as an end user don't you?

 

It makes no difference to me where the files are stored, I just use the times the Windows API returns in the FindFirstFile type commands.

[rastan]

Even if they're stored differently in FAT and NTFS, surely you still see the same time as an end user don't you?

 

Not necessarily. FAT timestamps always look the same because the FAT filesystem has no concept of a timezone. However, internally all NTFS timestamps are stored in UTC (which is basically the same as the GMT timezone). For display purposes Windows adjusts the time to take account of the timezone and daylight savings settings of your computer. Because the clocks go forward and back in Britain, if you save an NTFS file in winter and then look at the timestamp in summer, it will appear to have changed by one hour. The timestamps will also appear to change if you change your computer's timezone settings.

 

This isn't really a problem until you try to convert from one system to another (see my earlier post for details).

 

In my opinion, files that originated from a fat partition should be stored in local time and files that came from a NTFS partition should be stored with their timestamps relative to the UTC/GMT timezone.