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

[wimble.livejournal.com]

What if you save it first to the local drive, and then copy it to the samba drive? Or if you try it on a pre-existing local file?

Remember to check the time stamps on the local files as well, just in case.

That will, at least, explain whether it's the email client that's causing the problem, or the samba mount.

[j4.livejournal.com]

Sorry, yes, clarification: if I save it first to the local drive, or to another drive where it doesn't already exist, and then move/copy it (with mv or cp), it updates the timestamp. (If I copy and paste in Windows Explorer, it doesn't.)

Actually this doesn't clarify at all, does it? I am very confused now.

[sesquipedality.livejournal.com]

Delete the file you're replacing first.

[j4.livejournal.com]

This may prove to be the workaround. It's just this is a thing I have to do regularly, & it's much easier to go "Yes, I would like to save these 15 files to this directory" and then just click "yes, DO overwrite it" for each one than to go through and match up the 15 files and delete them before saving them all. If you see what I mean.

Oh, hang on, wait.. Either I'm going mad, or it really is true that if I delete the old file first and then save the new attachment it still has a really old timestamp! I think something is screwy with these files. How can you edit a file and not change its timestamp??

Time passes slowly and fades away

[hoiho.livejournal.com]

You've entered a wormhole...

What colour is the sky?

[nja.livejournal.com]

A little experimentation with Windows suggests that it keeps the timestamp of the file which was originally sent as an attachment - I've just emailed myself a JPEG file created in December, deleted the original file and saved the emailed copy, and it still has the same timestamp. If I save it under a different name, it still has the December "modified" timestamp, but it was apparently "created" today. Saved under the old name it was both created and modified in December.

So basically, (sit down before you read this next bit and have the smelling salts handy), Windows doesn't do this properly.

[oldbloke.livejournal.com]

I've never looked into it deeply, but I always had the feeling there was a logic to it, but that it was a counter-intuitive one.

[nja.livejournal.com]

Addendum - you don't even have to go via email. Copy-paste results in a file called "copy of XXX", which was created today and modified in December. Using -M, -C and -A in Perl gives the same result. In fact, there seems to be no difference between the modification and last access timestamps in Windows (if I open the file, nothing changes, and if I modify the file and save it, both change). I may fire up the Linux box now and play around on that. Beats working, doesn't it?

[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.

[sparrowsion]

Windows has this fucked-up thing which means that if you delete a file and quickly recreate it you can get the metadata of the old file. I thought it was a "feature" of NTFS, but it might be the general Windows file interface and therefore apply to samba files as well.