rename file from parent metadata does not change attachment

paulvdh

Since recently, when I choose 'rename file from parent metadata' only the file name in the file system is changed, not the attachment name which is shown in zotero. Zotero can no longer find the file and I cannot open the file from zotero.
When I choose 'view pdf' I get a message 'the attached file could not be found' with a 'locate...' button. This button brings me to the correct directory and I can re-link the file to the attachment. The name of the attachment is still the old name and needs to be changed manually, but at least I can now open the file from zotero
Before the file and the attachment name changed, and the link remained operational

Any others with this problem?

Paul
Using 4.0.16 in firefox

dstillman

To be clear, by "attachment name which is shown in zotero" do you mean the "Filename:" field in the right-hand pane? Because I don't think the attachment title — what's shown in the middle pane — has ever been changed (and that also wouldn't affect being able to open the file).

This works for me. Provide a Debug ID that shows you opening an attachment, renaming it with that option, and then trying to open it again unsuccessfully.

paulvdh

Hi,

Thanks for responding. I must admit the conditions for issue are a bit different than first thought:
It seems not to be a version problem but a file attribute issue of the attachment: the file(s) in question has 'read only' set.

Updated issue description: when the 'read only' attribute is set on an attached file, the option 'rename file from parent metadata' _does_ change the file name on the disk, but not any of the file data in zotero (neither the 'Filename:' item, nor the bold attachment name just above it in the right hand pane ('attachment title'?).

Steps to reproduce:
select an item in zotero and expand to show the attached items
right-click an attachment en select 'show file'
In the 'select a file' dialog: right click the attached file and select 'properties'
Enable read only and click ok
click cancel to leave the 'select a file' dialog
select the parent item of the attachment and change either the title, author(s) or date
right-click the same attachment again en select 'rename file from parent metadata'
result: none of the filename/attachment title data is changed in zotero. 'View pdf' gives a 'file not found' dialog because the file name on the disk was changed but the zotero database was not updated accordingly. Pressing 'locate' opens a 'select a file' dialog in the correct directory, showing the _changed_ file name. Selecting the file and pressing ok restores the ability to view the attachment from zotero.

Expected behaviour: same as for non-read-only attachments. The option 'rename file from parent metadata' changes the file name on the disk, _and_ both the 'Filename:' item, and attachment title in the zotero database.
This is the behaviour when the 'read only' attribute is not set on the attached file. In contrast to what you observe: the attachment title has always changed for me together with the file name with the 'rename from parent metadata' option.


The Debug ID is D1461863154.
Note: this logs only the rename action since this is when the error occurs.

Paul

dstillman

[JavaScript Error: "[Exception... "Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsIFile.lastModifiedTime]" nsresult: "0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)" location: "JS frame :: chrome://zotero/content/xpcom/data/item.js :: Zotero.Item.prototype.renameAttachmentFile :: line 3041" data: no]" {file: "chrome://zotero/content/xpcom/data/item.js" line: 3055}]

So this is happening because after Zotero renames a file it also updates its modification time, because that's what Zotero uses to trigger uploading of the file to the server for syncing. But while a rename is apparently allowed by the filesystem even if the file is marked read-only, changing the modification time isn't. (The former kind of seems like a Windows bug, but it's true that renaming a file on its own doesn't normally change the file's modification time, so it sort of makes sense under that limited logic. And OS X, oddly, allows both actions when a file is read-only.)

In 4.1 we might have more flexibility in terms of not requiring a mod time change after a rename (which would be nice, since that's that's the filesystem's behavior), but for now the best we can do is roll back the name change if the rename fails and notify the user that the file is read-only.

dstillman

Ticket created.

paulvdh

Hi

Thanks again for taking this seriously.

Maybe the windows designers thought the change date should only be about the file contents, not the metadata such as file name. I think it is not a bug then, is it?

An other suggestion: the read-only property was not set by me, therefore it must have been set when the pdf attachment was downloaded from IEEE. I didn't know these attributes could be transmitted over ftp/http, I thought these were only local. Also, it seems to be file specific since I have dozens of IEEE pdfs in zotero without the read-only attribute set.
Is it a bad idea (and why) if zotero cleared the read-only attibute on importing an attachment?

Paul

dstillman

Yeah, what causes the read-only attribute to be set it still mostly a mystery to me. Certainly shouldn't be transmitted over the network in any way. Usually this seems to be related to security software.

Is it a bad idea (and why) if zotero cleared the read-only attibute on importing an attachment?

At least until recently I don't think we had any ability to do so. It's possible we do with now with some new functionality available in the Mozilla framework (the 'winSecurity' option in OS.File, if anyone's interested), though I haven't tried, and parts of Zotero would need to be rewritten in order to use it.

Anyway, this is fixed (thanks to Aurimas) in the latest 4.0 Branch dev XPI, and the fix will be included in 4.0.17.