clone 376103 -1 retitle -1 recode: bad default: hides file modifications by restoring mtimes reassign -1 recode severity 376103 normal thanks
[Vincent Lefevre]
> The "recode" utility does not update the timestamp (I assume this is
> a feature).
Yeah, well ... I don't know whose brilliant idea it was, but it seems
this _is_ documented:
`--touch'
The _touch_ option is meaningful only when files are recoded over
themselves. Without it, the time-stamps associated with files are
preserved, to reflect the fact that changing the code of a file
does not really alter its informational contents.
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!
(Yes, I know the 'copy' builtin of COMMAND.COM on MS-DOS does this.
It's broken too.)
I'm copying this bug to recode. In my opinion, 'svn' and 'make' should
be entitled to assume that the user has been honest about modifications
of her own files.
> Looking at the timestamp (mtime) isn't sufficient to quickly decide
> whether a file has been modified. Under Unix, the ctime should be
> taken into account too (and/or possibly the inode).
What the #*&$@ is the mtime for, then? Is it just a pretty but useless
field for 'ls -l' to display? In my opinion, the whole _point_ of the
mtime is to tell you when a file was modified. Yes, you're allowed to
cheat and back-date a file, but when you decide to lie to the system,
you have to realise that you just lied to the system and the system is
allowed to be confused.
> Note also that the file size has changed after recode.
We can't rely on that, it isn't always true. And it certainly won't be
true if you do something even more clever than recode, like an in-place
rot13, to prove that you can still break your own working copy.
* * *
In summary, the patch you want me to apply is quite simple, but in
essence you're asking me to tell svn to ignore all mtimes in favor of
ctimes. And really, it seems to me that the rationale for doing this
also applies to every other Unix program -- and thus implies that the
mtime field shouldn't exist at all.
It's also not a patch I can send upstream, as it will do the wrong
thing on Windows and OS/2. This increases the annoyance factor even
more.
Thanks,
Peter
signature.asc
Description: Digital signature
