mtime is not saved

zotero disregards the "Last-Modified" http header, and does not set the modified date of downloaded files accordingly. This causes, for example, pdfs to show the download date under "Modified" instead of the actual date the file was last modified.
  • the last modified field refers to the item in Zotero, not the file. It's intended for organization in Zotero, not for citations (in fact, it can't be cited).
  • I referred to the Modified field of a downloaded attachment (ie., a PDF), not the Modified field of the item to which it has been attached. The Modified field of a downloaded attachment is the modification time of the respective file. In fact, you can see that it changes as you modify the attachment file.
  • right - but think of this as displaying the way Zotero keeps track of changes for syncing. Yes, if you change the file in the future the modified data changes (and the item should re-sync). But it was never supposed to display the original modified date of a file - the initial modified date is always the same as the accessed date (which has it's own advantages - e.g. you can check easily if you've edited a file since importing it into Zotero).
    If that's important to you, you can explain why and make it a feature request, but this is working as intended.
  • What zotero displays is clearly the modification date of the file, as kept track of by the file system. If zotero downloads a file, its modification date should not be changed, since downloading is not modifying. So IMO this is clearly a bug, not a feature request. I do not see how syncing could possibly be relevant here. If I download a file, zotero knows it's new and that means it needs to be synced. If I modify the file, it will still change modification date and again, zotero knows it needs to be synced. If, for any reason, zotero needs to keep track of the download/import date, it needs to do so in a different way, since, if you actually modify a downloaded/imported file, the modification date will be different from the download/import date even with the current behaviour.
  • I really have no interest in discussing the semantics of whether this is a bug or not.
    If you want it changed, provide a rational beyond "that's how it should be" and we can discuss this productively. My argument for leaving this as is is that it allows you to check whether you've edited a file since importing it in Zotero". What's your use case for changing it?
  • The use is knowing when the file was last modified; after all, the field says "Modified", not "Imported". I agree that the import date is valuable information, but it should be separate, especially since modification of the file will currently overwrite it anyway. See http://en.wikipedia.org/wiki/Principle_of_least_astonishment Concerning your argument, I see that it would be nice to be able to do this, but how does zotero currently allow me to check whether I've edited a file since importing any better than if it would preserve the modification date on downloading?
  • rtc1: Just to be clear, you're talking solely about the modification time set on the file after the initial save from a website, yes?

    I think this is pretty fairly called a feature request, since even Firefox doesn't seem to override the mod time of downloaded files, but I don't have any objection to following Last-Modified if it's available.

    adamsmith:
    My argument for leaving this as is is that it allows you to check whether you've edited a file since importing it in Zotero".
    You'd still be able to do this just by seeing if the file's mod time was more recent than the Date Added/Accessed of the parent item, no?
  • but how does zotero currently allow me to check whether I've edited a file since importing any better than if it would preserve the modification date on downloading?
    by comparing modified and accessed dates. If the former is after the latter the file has been modified after import.
    As for least astonishment - you're the first person to mention this in 7 years of Zotero, so it's not like this is a constant source of consternation and I'd argue that changing 7 year old behavior creates astonishment in itself so there'd really have to be a good reason for it. I'm not convinced. I'm not going to make the call in the end, and maybe Dan sees this differently, but changing the current behavior would seem like a mistake to me.
  • You'd still be able to do this just by seeing if the file's mod time was more recent than the Date Added/Accessed of the parent item, no?
    ah yes, you're right - that would still work. My bad.
  • [...] even Firefox doesn't seem to override the mod time of downloaded files [...]
    I assume that by this you mean that Firefox sets Modified time = Accessed Time = download timestamp? At least that's the behavior I'm seeing.

    FWIW, I don't see why we shouldn't maintain the mtime if we can unless this currently interferes with sync.

    On the other hand, I don't really see much use for this behavior either. IMO, last modified time as supplied by the remote web server is quite useless. I don't think rtc1 has presented a real use case either. We do preserve mtime on import from RDF, RIS, etc., which is much more important.
  • edited April 26, 2013
    I assume that by this you mean that Firefox sets Modified time = Accessed Time = download timestamp? At least that's the behavior I'm seeing.
    Yeah, but that's just the filesystem/OS. Firefox isn't changing it from the default file creation time, I mean.
  • http://lists.w3.org/Archives/Public/www-tag/2011Nov/0026.html

    I for one consider my local copy of a file to be separate from the server's copy unless it is being synced in some way rather than simply downloaded. I find it quite astonishing when the modified date is earlier than the created date in reference to the same file.
  • that's consistent behavior at least with copying files on Windows

    http://support.microsoft.com/kb/299648
  • Dan Stillman: "Just to be clear, you're talking solely about the modification time set on the file after the initial save from a website, yes?" Yes. As this seems to be controversial, it would be nice to have at least some option, so please consider it a feature request if you think that's more reasonable.

    fcheslack: "I for one consider my local copy of a file to be separate from the server's copy unless it is being synced in some way rather than simply downloaded." But what is the difference? The entire discussion thread at http://lists.w3.org/Archives/Public/www-tag/2011Nov/0025.html is very unfortunate, the simple argument that in doubt, to preserve is better than not to preserve, causes many replies with empty and meaningless academic statements.

    aurimas: "consistent behavior at least with copying files on Windows" I'd consider zotero's download to be file archiving, and cp --archive from GNU coreutils preserves the mtime. wget, by default, does so, too. It is unfortunate that firefox doesn't seem to offer an option, only as an addon. Last word on this seems still not to have been spoken, see https://bugzilla.mozilla.org/show_bug.cgi?id=178506#c249 which refers to the mailing list disucssion mentioned by fcheslack. ext4fs has crtime which tells you when you downloaded the file. The mtime seems not a place to rely on for this information anyway.
  • edited April 28, 2013
    aurimas: "consistent behavior at least with copying files on Windows" I'd consider zotero's download to be file archiving, and cp --archive from GNU coreutils preserves the mtime. wget, by default, does so, too. It is unfortunate that firefox doesn't seem to offer an option, only as an addon
    Just to be clear, I was referring to fcheslack's comment
    I find it quite astonishing when the modified date is earlier than the created date in reference to the same file.
    Which is what happens in Windows if you copy files from one location to another. ctime is set to the current timestamp, while mtime is preserved, so ctime > mtime.

    As I said before, I don't really see very much use in looking at mtime of files downloaded by Zotero, but clearly you have a reason. I also don't see any down side to preserving the mtime where possible as long as it doesn't interfere with sync (and I think Dan has implied that it doesn't).

    It may help move this feature request faster if you had a more solid use case than
    how does zotero currently allow me to check whether I've edited a file since importing any better than if it would preserve the modification date on downloading?
    which Dan addressed with
    You'd still be able to do this just by seeing if the file's mod time was more recent than the Date Added/Accessed of the parent item, no?
    As it stands now, it doesn't look like it would be very high on the todo list.
Sign In or Register to comment.