Zotero update fails because it was unable to create a file

dmk

I am running Linux Mint 17 with Firefox 32 and Zotero 4.0.22 on a brand new desktop that has never synced to zotero before. When I try to sync my account with zotero servers if fails with the error:

The file '22BU8RKA/png-base64,ivborw0kggoaaaansuheugaaaaoaaaakcayaaacnms+9aaaagxrfwhrtb2z0d2fyzqbbzg9izsbjbwfnzvjlywr5ccllpaaaabtjrefuenpizgbgagagajaxealgfvjhiucaaqdcngcugqgmqwaaaabjru5erkjggg==' could not be created in the Zotero 'storage' directory.

I filed a report at: 1203667411.

Please help me with this so I can finish syncing.

Thanks,
David

aurimas

See if you can create a text file in your home directory and rename it to png-base64,ivborw0kggoaaaansuheugaaaaoaaaakcayaaacnms+9aaaagxrfwhrtb2z0d2fyzqbbzg9izsbjbwfnzvjlywr5ccllpaaaabtjrefuenpizgbgagagajaxealgfvjhiucaaqdcngcugqgmqwaaaabjru5erkjggg== All of those should be allowed characters under Linux, but I see some bug reports popping up regarding commas. The file length should be within the 255 character limit (it's at 175).

If you want a quick solution and you don't care about the Snapshot attachment for the item in question, you can go to https://www.zotero.org/dmk/items/itemKey/22BU8RKA and delete (move to Trash), then empty your Trash online. The sync should then go through.

In general, looks like we need to fix the Snapshot function to not save data URIs as files.

dstillman

Aurimas: Agreed re: data URIs, but I think we can also run into trouble on Linux when filesystem (or, really, filename) encryption is in use, which brings the max filename length below 255. Same issue here. I'm working on a fix.

aurimas

For reference https://bugs.launchpad.net/ecryptfs/+bug/344878 Max file length of 143

dstillman

Thanks. I've made a new function, Zotero.Utilities.Internal.createShortened(file, type, mode), that takes some of the previous shortening code used in syncing and puts it in one place, along with better handling of encrypted filenames using the 143-char cutoff.

dmk, I need to do a bit more testing, but I'll put out a beta version later today that should handle this better. Stay tuned.

aurimas

Is this going to be able to deal with existing long file names? I can't think of how you would manage that in snapshots though.

dstillman

What do you mean by existing file names? This gets triggered during file sync when an incoming file is too long for the current system.

For snapshots it shortens but doesn't relink (since, as you say, that would be quite difficult), so those just break and stay in the attachment directory. We could probably start calling this function from the snapshot-saving code, though.

aurimas

For snapshots it shortens but doesn't relink (since, as you say, that would be quite difficult), so those just break and stay in the attachment directory.

Right, that's what I meant. Breaking snapshots is better than breaking syncing, I guess.

We could probably start calling this function from the snapshot-saving code, though.

I've always thought that there's no point in keeping file names longer than 50 characters or so, particularly for snapshots.

dstillman

I've always thought that there's no point in keeping file names longer than 50 characters or so, particularly for snapshots.

I think it makes sense to keep single-file filenames as long as possible, but I agree that for snapshots 50 or so would be fine.

dmk

Hi,

Sorry for the radio silence - I have been busy with other things. Encryption and long filenames are indeed the problems here - my home is encrypted.

I would be happy to test a fix, just let me know when to grab the beta. I deleted the attachment mentioned above, but it just advances to the next one and has the same problem...

Thanks,
David

dstillman

OK, try the latest 4.0 Beta and see if that helps.

dmk

Sorry for the long silence. I have been traveling for work. It appears that the new beta has fixed the problem as it is now busily trying to finish syncing my database. Thanks for the help!

dstillman

OK, great. This fix will be included in 4.0.23.