ISO original file dates change to current date

[maru7711]

When using Rufus I noticed all file dates change to the current date. Would it be possible to keep the original ISO file dates during ISO extraction to the USB drive ?

[pbatard]

You know, for the longest of time, I had the following comment in the ISO handling for Rufus (src/iso.c):

// TODO: Timestamp & permissions preservation

I never took action on this, because my idea was to see if anybody would ever request timestamp preservation. After 2 years, and nobody complaining about it, I thought the message was clear: It didn't look like anybody cared about timestamp preservation, so I removed that comment.

As such, right now, I think I'll need a strong business case to decide to look into adding timestamp preservation. Do you have scenario where you timestamp preservation on file extraction needs to occur for some things to work?

I have to say that not having timestamp preservation makes the code simpler, and probably helps make ISO extraction a bit faster when there are a lot of small files, so I don't think I want to add it without some justification as to why it is required. Plus there may actually be people who rely on timestamps not being preserved (to find out when their UFD was created for instance), so I have to consider the possibility that, if I add it, I may receive complaints to remove it...

This being said, I am definitely interested to hear about cases where timestamp preservation would help, as I haven't been able to come with a good justification for it so far. Are their ISOs out there that look at timestamps to perform special actions?

[maru7711]

Thank you for your quick reply. You can mark my inquiry as closed. As a habit I have been using UltraISO to extract files to the USB and the timestamps have been preserved. You are correct it does not really change anything. Thanks again for creating a wonderful program. I will use your program in the future with a new laptop with UEFI/GPT.

Sincerely,

Marcos O

[matidio]

Yes, it is strange that nobody requested this before. I think it can be explained by the fact that this file information isn't used often. But it is crucial when other methods to distinguish files are not present. There is a reason that file dates exist. Anyway the frequency someone depends on this metadata (file origin date) doesn't necessarily mean it is a metadata negligible. One case can be sufficient to create a lot of problems. Let alone that someone could have implemented a logic based on the file date and Rufus alters its date behind his back. (BTW the way I detected it)

So, I think, the fact that nobody asked until now can't be accepted as a decisive argument.

At this point the discussion whether to preserve the origin date of the source or not, can be reduced to the question whether file dates are useless or not. And I think we both agree that this is not the case.

Not preserving the origin file dates means deleting an important quality of the origin files equivalent to Rufus is altering the original files. No software should do this (without being asked) in particular where it should be beyond the scope of Rufus.

[pbatard]

389, 8b880a7d31066861064f7b6589972e1c7dc5a2a4, ChangeLog, FAQ and the Alt-T cheat mode should be of interest to you.

Or, in other words, be weary of trying to reopen an issue that is 2 years old without first performing a comprehensive search to find out if it still applies.

[pbatard]

Also

the frequency someone depends on this (...) doesn't necessarily mean it is (...) negligible. One case can be sufficient to create a lot of problems.

Please describe a real-life case. The reason it's a cheat mode is that I still have to find a real-life scenario where preserving timestamps actually matters.

It's a bit of a cop out to say "Oh well, you cannot say for sure this is unimportant, so you MUST treat it as critical just in case", because then EVERYTHING becomes critical. That's just not realistic.

Heck I could venture scenario where it is critical for someone who creates a handful of bootable USB drives from the same ISO to be able to differentiate them, in which case NOT having the original timestamp can be crucial. That's actually part of the reason I don't enable timestamp preservation by default.

Finally, just so you know, once you activate timestamp preservation, it will remain active between sessions (unless you manually disable it).

[matidio]

Please describe a real-life case. The reason it's a cheat mode is that I still have to find a real-life scenario where preserving timestamps actually matters.

My real-life case is that I create various boot images for windows installations with the same file base (same windows installation files) adding custom logic to replace administrative group policy templates. The logic + the files are part of the source ISO so object of the date change. As those files fundamentally are different only by the date when they were replaced by Windows updates the simplest and sufficient logic is to use the origin file date. If the date of the added files is all the same the logic doesn't work anymore and I had to introduce a far more complicated logic. I have no reason to do so because I can trust the file date. There are reasons why file dates exist.

But the problem is a conceptual one. From my point of view it is not correct to wait until one says, ups, now it's needed to preserve the file date because I can't resolve the problem otherwise. Rufus shouldn't alter the source files, it's not its job, it's a bug or at least a not so nice side effect. And to resolve the problem only upon request or occurrence knowing there is this problem, always my view, not the way to handle those cases.

Finally, just so you know, once you activate time stamp preservation, it will remain active between sessions (unless you manually disable it).

That's fine with me and thanks for the hint but I think it should be the default. The same reason as above. I don't expect any variations of my files on the boot stick.

389, 8b880a7, ChangeLog, FAQ and the Alt-T cheat mode should be of interest to you.

Or, in other words, be weary of trying to reopen an issue that is 2 years old without first performing a comprehensive search to find out if it still applies.

You're right. My fault to not investigate further. I did a Google search whether others observed the same behavior and one of the first link was this issue. Reading your seemingly conclusive answer I wrote the comment.

Thanks for the Alt-T solution (I always think it should be the default :-). Hopefully it solves my issue. Thanks again for your answer

[pbatard]

Rufus shouldn't alter the source files

I disagree. First of all, Rufus doesn't alter the source files and you are deliberately trying to misrepresent the issue in an attempt to present it as bad behaviour, when that isn't the case. Rufus simply updates the timestamps of the copy it creates of some files, which is a big difference. And I explained that I very much see scenarios where people will prefer to get the timestamp with which the copy took place by default (it is my belief that it will be useful for more people this way, as a simple look at the metadata of any file will tell you precisely when that USB was created, which might be a crucial piece of information for regular folks), rather than the original timestamp of the source.

A bootable USB is not the same thing as a bootable ISO. For one thing it uses a completely different file system, and there is absolutely no mandate for OSes or applications, when media or file system translation occur, to preserve timestamps.

In fact, when you download a file from the internet, you will see that most browsers do not preserve timestamps, but instead set them to the current date/time (which, I will maintain, is probably more useful than preserving it). So if your approach is that updating a timestamps to the time a copy of a file was created is always wrong, you may want to contact the Mozilla foundation and other browser manufacturers, and also ask them to change their default behaviour.

Also, you need to understand that I have given a chance for YEARS, for people to demonstrate how not preserving timestamps was impairing their usage of bootable drives created by Rufus, and I have to stress out that you are the only person I have seen that tried to present a semi legitimate one (yet something that I would qualify brittle - surely the better way to identify files that you need to alter is to isolate some unique part of their content, rather than try to use metadata that is NEVER guaranteed by an OS or app not to be modified — for instance, do you know that, depending on the ISO content, Rufus may very well modify some files to make it USB bootable, in which case it will of course set the timestamp to the time of modification, regardless of whether timestamp preservation is active, so as not to be deceptive about what it's doing?).

I actually went far beyond what was required by adding the cheat mode, despite not being given any good reason to include such a feature. Just so you know, Rufus is downloaded close to 2 million times each month, which means that if this was as big an issue as what you are trying to present, it would be exceedingly obvious. But when, after all these years, only a single person comes with a scenario that requires adding scripts (instead of, and this is what I have really been waiting for, a popular enough bootable ISO that will break, without adding anything extra, when converted to USB, because of timestamp non-preservation), it's hard to see it as receivable.

Therefore, I have had all the proof I need to reach the conclusion that, NO, timestamp preservation is not a critical feature that Rufus needs to provide by default and that the few people who might have a slight requirement for it will have more than enough with the Alt-T cheat mode.

Furthermore, I will add that if you are trying to use Rufus in a sysadmin context, you should realize that Rufus was never designed to be used as a sysadmin tool. This is a common issue I have with people who regularly ask me to add a very specific feature that will make their power-user/sysadmin life easier.

Rufus is first and foremost a utility that is meant to be used by the general public. If the feature or change of behaviour you request will actually improve Rufus use for the general public, I will always consider it (and right now, I see timestamp preservation by default as less beneficial for the public than the alternative). But if your change is about simplifying your sysadmin's life, I will respectfully have that you either use a tool that is better suited to your needs, or a set of scripts (which I have to assume, as a sysadmin, you should have enough expertise to craft yourself) as I can guarantee that you will always be disappointed with the design decisions that are taken in Rufus otherwise.

[matidio]

Thanks for your explanations. I read them but your argumentation doesn't convince at all. It has no relevance whether I'm a sysadmin or not (btw I'm not). You write a lot of assumptions without prove or relevance. Comparing downloading from Internet with Rufus' copying, sorry, but these are apples and oranges. And it's not that I would like to save my simple logic. It doesn't matter at all. It needs no time to rewrite it. Indeed I'm not asking a feature. You missed my whole point. Arguing with number of downloads doesn't help if it is a bug. I'm still the opinion that files which are in no relation with the creation of the boot media shouldn't be altered. Source and destination filesystems have very similar concepts, are based on the same standards. BTW Microsoft itself makes a translation of file systems preserving time stamps, without any mandate. For correctness it doesn't need a mandate. Identifying by the files' date when the USB stick has been created, you're serious?! Some thousand files which show the creation date of the stick. Yes, that's important ... loosing the original time stamps of the files is negligible, fore sure.

The whole issue here is whether in your eyes it is a bug or a feature. You are convinced it's a feature and that's all what matters.

I think we can stop the discussion here.

[pbatard]

The whole issue here is whether in your eyes it is a bug or a feature. You are convinced it's a feature and that's all what matters.

Ah, now you are trying to use the old "Someone who overlooked a bug is claiming that it's a feature to get out of fixing it" argument, to try to imply that there still exists a bug here...

Except that it doesn't fly, because I did consider whether I should enable timestamp preservation by default in Rufus when I added the cheat mode, and I very deliberately chose not to do that. So please bear in mind that I didn't flip a coin or let a personal preference dictate my decision when it came to choosing whether timestamps should be preserved by default in Rufus or not, but, after considering the pros and cons, asserted that, in the context of what Rufus is used for, the cons outweighed the pros.

And you know what, I'm getting somewhat tired of having to regularly justify very deliberate design decisions to people who just want to classify anything that goes against their narrow view of what the application is meant to be used for, as a bug.

I can't prevent you from trying to delude yourself that this is a bug, if that's how you really want to convince yourself it is, but don't expect me to stop telling you that you are 100% wrong in that respect. Also, I can't help to find it strange that, every time I put forward the large number of people who download Rufus (which is only aimed at giving people some idea about the level of insider feedback an application like Rufus can generate about how the application is being mostly used, and by whom), people try to dismiss it as irrelevant in the context of making an educated design decision.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.