Can you provide a Debug ID for the sync attempt (if that's indeed what you're referring to—you don't say) that produces this error?

This appears to be an issue with a filename. We've already fixed a number of such issues for the next release in the latest dev builds, but this may be a new one, and possibly due to this being on a network share.

Assuming you're syncing from another computer, open the 'storage' directory within your Zotero data directory on that computer, go into the 'PNESTQMM' folder, and find the very long filename beginning with "de" and ending with "36". E-mail that file to yourself, and then, on this Windows XP computer, try saving it to the same 'PNESTQMM' directory (which you may have to create) within your Zotero data directory's 'storage' directory. If you get an error, let us know what it is.

I do have the PNESTQMM folder here (on the network share where the profile is of the firefox on this windows xp computer), but without the file with the long name. When I get home this afternoon I'll find the file on my home computer (Linux) and tomorrow I'll try to copy it here. I'll let you know.

This wasn't intended to fix the problem—simply to figure out why the file can't be saved to that location. See my previous post for the things that would be helpful to try.

Don't do anything with sync for the moment.

if saving of that file fails, it'd be helpful to know what modifications (shortening the file, shortening the file extension but increasing the length before the period to compensate, saving the file to a directory higher up in the path, removing certain characters (e.g., '+'), etc.) allow the file to save.

A bit of context, if you're confused: I'm able to save the file with the full filename to the Desktop on an XP system, so the filename itself is valid on NTFS filesystems (as specifications for NTFS suggest it should be), and the full path you were using was below the NTFS path length limit. Zotero only corrects for the limitations we know of, but the network share may have additional limitations. So we need to know what variations of the filename/location allow the file to save on the network share to be able to correct for this in Zotero itself.

As far as I can see, it's a problem of file name length in combination with the path: files with names above a certain length will not copy to the firefox profile folder, but will copy higher up in the path. I'll try to figure out the exact length.

For the path length (which includes the filename), you might start by checking around 128 (which is the next most likely limit if it's not 255).

Hmm. NWFS supposedly doesn't define any limits on path length, so I'm not sure where that's coming from. We can look into this further, but any "fix" on our end may very well just be a more informative error message, since, unless we can figure out what's causing that limitation and find relevant documentation on it, we can't really correct for it.

Your best bet would be to switch to a custom data directory near the root of the network share path from the Advanced pane of the Zotero preferences. The filename in question—at least, the first one that was failing—was 152 characters, which gives you a little bit of breathing room if the path limit is indeed 198 and you use a data directory location near the root.

That's all right—thanks. For now I think we'll just add a more informative error message, and if other reports surface, we'll try to see if there's a common denominator. But most likely there will just be these arbitrary, differing limits in various network environments.

Where did you get the 198, though? From your debug output, it looks like the full path length of the PNESTQMM directory was 97 characters, so, if that's where you were trying to save the files, 124 (maximum) characters would put the limit at 221 (or somewhere close to there).

At any rate, it's probably not worth worrying about too much. It makes sense for Zotero to automatically shorten files to work around standard limitations, but accounting for every odd limit in every network environment isn't possible, so a more helpful error message when a file can't be created is probably the best thing to do.

I don't totally follow, but forget about the original file and path. Just create an empty file in the root and make the filename as long as you can. Once you find the limit, shorten the filename and move the file into a subdirectory, and then increase the filename length until you hit the error again. Then check to see if the deeper path length limit matches what you got at the root. If it's actually a path length limit, it should be reproducible at any depth by adjusting the filename according to how much of the limit the folder path requires.

OK, thanks for checking. That's at least within striking distance of 260 characters, which is a known limit for some parts of Windows. My best guess is that, even though the network share is mapped to a drive letter, Windows needs to use the full UNC path to your space on the share, which, with the server name, volume, and path to your account directory, could reasonably take up 44 characters. Zotero only has the drive letter, though, so the best it can do is wait for an error and handle it a bit more gracefully.

I'm having running into the same nsIFile.create error, albeit with a very different setup. If there's a path length restriction, I'm not sure where it's coming from.

Error report: 1647701655
Debug: D40097628

I'm running Firefox 3.6.3 under Ubuntu 9.10, with syncing via mydrive.ch. My Zotero storage directory is mounted from the NTFS partition on my hard drive, so there is a chance that NTFS file length limitations are nonetheless to blame.

Can you (Dan, probably) take a look and tell me what directory is to blame, so I can work this out? I can't make head or tail of the debug output.