Report ID: 1084601263

mark.diamond

I have an existing entry in my library. It has a single PDF attachment. If I right click on the entry, the context menu appears. If I then choose "Add attachment", select a PDF file, and click OK, the error appears and the would-be-attachment is not, in fact, attached. Moreover, it then becomes impossible to get the context menu to appear again when right clicking on that original entry, notwithstanding that the context menu will appear if I right click on some other entry. It is worth adding that I have tried deleting the entire entry and starting from scratch, but the same thing happens.

It isn't clear to me whether one is only permitted a single attachment per entry (in which case it would be helpful if an error message appeared when trying to make a second attachment), or whether this is a bug.

mark.diamond

As a follow on ... it is now clear to me that two attachments under the same entry *are* possible. I have achieved this by logging into my Zotero account and doing the attachment with the browser, and then resyncing my library ... where the second attachment appears correctly.

mark.diamond

... so, what is the causing the error my attempt to attach the file locally?

dstillman

[JavaScript Error: "Unix error 1 during operation setDates on file /media/[…]/windrive/Users/[…]/Zotero/storage/WUFRAKHZ/[…].pdf (Operation not permitted)" {file: "(unknown module)" line: 0}]

It's a permissions problem on your computer.

mark.diamond

Thanks for the reply. Unfortunately, as an average user, "it's a permissions problem" didn't help me much, but I have sought advice from very non-average users. I gather now that the problem is that Zotero is trying to change a file date on a server where I don't have permission to adjust file dates.

The bizarre thing is, however, that this isn't really an explanation.
(i) The error has only appeared since updating Zotero.
(ii) It isn't clear why Zotero is (in the latest version) trying to set a date when in an earlier version it didn't
(iii) it isn't clear why Zotero is allowing me to create the main entry but not allowing me to attach a second attachment

dstillman

This isn't a Zotero problem. Something on your system or on the network drive is preventing Zotero from updating files within its data directory. Everything else is irrelevant — the version of Zotero, why this particular file is being updated, etc. Zotero needs to be able to update files in its data directory, including writing to the file, changing the timestamps, and changing the file mode (which is also failing here).

We generally assume that people using Linux know how to debug this stuff themselves (hence the lack of further elaboration above), but if you don't, you'll need to ask someone to help you fix the permissions, since this is entirely specific to your setup and not really related to Zotero at all.

mark.diamond

Thank you again for the reply. I hope I don't appear rude. I don't mean to be ... but having sought assistance from people who do understand the file system, it is still not clear what is going on. The suggestion that the Zotero version is irrelevant doesn't seem to fit with the facts.

(i) the file system permissions have not changed in the time since Zotero was working, and the time it has stopped working; something about Zotero has changed.

(ii) If I attach an attachment through the web-browser and then sync my local version with the cloud version, all is well, even now with the apparent permissions problem.
(iii) Point ii above indicates that it must be the case that whatever permissions that currently exist are sufficient for Zotero to form a new entry together with an attachment ... but it isn't sufficient when the attachment is attempted locally.

So I'm trying to understand what exactly it is that is being done with the direct attachment in terms of creating and setting file attributes from what would be done during the syncing. As I said, it worked fine under an older version of Zotero, so there is something about what Zotero is doing that might allow me to discover what kind of work-around could be used not that Zotero is not doing exactly what it used to do.

dstillman

You're going to have to take my word on this — I wrote most of the code in question. There've been no changes in Zotero relevant to this in years.

Zotero needs full access to files in its data directory. If it doesn't have that, you will get errors at various times, in the normal course of Zotero operation, and particularly during file syncing. If you want to know how Zotero works on a technical level, or review the last year of changes to the Zotero 5.0 code to verify that nothing relevant has changed here, you're welcome to do so. But if you want to use Zotero, you just need to fix your filesystem or disable any security software that might be preventing Zotero from writing to the filesystem.

If you're having trouble with a network drive, you should move your data directory back to the local disk. While network drives sometimes work, they frequently don't fully mirror the behavior of normal disks. File permissions are also often controlled server-side in a way that would require changes by a server administrator.

You can trigger date modification manually in Zotero by running this in Tools → Developer → Run JavaScript after modifying the path:

return await OS.File.setDates('/path/to/file/foo', false, new Date() - (Zotero.Utilities.rand(0, 86400000)))

That will set the mtime of the specified file to a random time within the last day.

That's all I can tell you here. This just isn't a problem in Zotero.

mark.diamond

Many thanks for taking the time for the longer reply. Most appreciated. I shall pass on the information. Cheers.

mark.diamond

For the solution to the problem, see the final part of the thread at:
https://forums.zotero.org/discussion/101897/linux-help-for-a-dual-boot-problem-that-affects-my-use-of-zotero#latest