[Vincent Lefevre] > Note that upstream doesn't want to fix the bug: > > http://svn.haxx.se/dev/archive-2007-03/0734.shtml
More to the point, they've chosen a different fix, which is to also store and look at file size. See #376124 for the recode maintainer's reaction - he doesn't seem to understand why changing the contents of a file then restoring the timestamp to hide your tracks is a foolish thing to do by default. I'm inclined to just wait until 1.5.0 is released upstream, with that fix, and use that. Upstream is right, as I said before: | I find it hard to put into words just how broken I think this is, and | I hope it's obvious enough that I don't have to. You just _don't_ | modify files on a Unix filesystem and then hide the fact that you did | so, unless the user has specifically indicated that there's a reason | to do this - as with 'cp -p' or 'rsync -t' or 'touch -t'. You don't | make this the _default_ behavior! My opinion hasn't changed. > [1] This includes recode, mv, unzip, rsync and scp (possibly with > options). The problem often occurs with recode, and even though it > should be quite rare with other tools, it can still occur. unzip, rsync and scp are poor examples. They restore a file's timestamp to a known value corresponding to a previous state of the same file. Think of it as a backup/restore operation. And even so, of those three, only unzip restores the timestamp by default.
signature.asc
Description: Digital signature
