Attachmental

[j4]

If I save a .csv file from an email attachment to a samba-mounted drive, overwriting a pre-existing file of the same name, it doesn't change the last-updated time for the file.

Quite apart from the general problems of no longer knowing when you last updated something, this means that if your processing script is looking for new updates in order to overwrite the old data with the new, this means the script completely fails to find the 'new' file, since according to its timestamp it is frankly old hat. Which is something of a nuisance.

This behaviour on the part of attachments has started quite randomly -- or rather, as far as I can tell, not due to any action on my part. Does anybody know of any way of persuading it to stop?

Comments

[nja.livejournal.com]

Linux behaves differently (but in my view equally wrongly), resetting the creation datestamp every time I change the file, but correctly updating only the last access timestamp when I do a read-only access.

So in summary: computers = rubbish.

[simont]

Unix doesn't have a creation timestamp, although you'd be forgiven for thinking it did if you just looked at the initials M, C and A...

The mtime is the last time the file's data was modified; the ctime is the last time its inode was modified. So in general, a change to the data automatically implies a change to the inode (if only to update the mtime!) and hence the ctime will generally be equal to or later than the mtime. Commands such as chmod can alter the ctime without affecting the mtime, but I can't immediately think of any that can possibly have the reverse effect.

(That said, a read-only access to the file updates the atime, but this doesn't count as enough of a change to cause the ctime to update. Quite why the mtime update couldn't have had that property as well I have no idea, but apparently it doesn't.)

It is annoying, and I think it would be much more useful to have a creation timestamp (although it's fiddly to work out the correct semantics in some situations - should a file change its creation timestamp if you rename another file over the top of it, for example?) in place of at least one of the ctime and mtime.

[nja.livejournal.com]

Doh! I have the blue camel open on the page where it says "Age of file in days since inode change", too. However, in my defence, Perl on Windows uses the -C operator to report the creation time.

[imc.livejournal.com]

The ctime is useful because it's the only one you can't change at will, so it tells you fairly consistently when the last change was made to the file (including touches and mode changes) and thus whether you need to back it up. On the other hand, the mtime is useful for lots of reasons. So I wouldn't want to see either of those replaced to make way for "creation time" even though the latter might be useful.

Writing to a file often involves such things as writing back the new file length — and possibly a new list of disk blocks — to the inode, so it's usually more complicated than just "updating the mtime". The ctime does also change when the file length doesn't, but that's probably done for consistency as well as the fact that it's useful for backup reasons as mentioned above.