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.

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

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.

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.

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

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!