Jump to content

rastan

Members
  • Content Count

    10
  • Joined

  • Last visited

About rastan

  • Rank
    ISF Newbie

Profile Information

  • Location
    UK
  1. 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.
  2. 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?
  3. I've just downloaded version 2.5.1.0 from the ImgBurn mirror site. Unfortunately, the checkbox you refer to seems to be missing.
  4. 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)?
  5. Hi LIGHTNING UK, I'm wondering whether this problem was ever fixed. Can you give me an update. Thanks.
  6. 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.
  7. rastan

    Verbatim Playing Fast'n'Loose With CDR Branding

    Hmmm, that's a bit worrying. Verbatim has always been my preferred brand in the past. Can anyone here suggest a good source for Taiyo Yuden DVDs in the UK? And which type of Taiyo Yuden DVD is generally considered to be the most durable for archiving purposes? I don't care about speed. Thanks. (p.s. I wanted to post these questions in the Media section but for some reason I'm not allowed to start new topics there).
  8. 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.
  9. 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.
  10. 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.
×

Important Information

By using this site, you agree to our Terms of Use.