report id: 55698221 (nsIFile.create)

Hello,

I got this nsIFile.create error. It's the first time I've seen it, and it came after updating my windows xp this morning. I'm using Firefox 3.5.6.

derxen
  • ... and I'm using zotero 2.0b7.6. The full error message: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIFile.create]

    derxen
  • 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?
  • Yes, sorry, it is a sync attempt. The debug id is: D205568248.

    thanks for your help.

    derxen
  • 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.
  • And 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.
  • 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.
  • I did as you suggested. The long file was actually 12 files with very long names. When I tried to copy them to the zotero storage folder on the xp computer (actually the network share where the firefox profile is) it gave me an error: 'The filename, directory name, or volume label syntax is incorrect'. Then I shortened the filenames, and I could copy them. I then started up firefox and zotero, but got the same sync error. Moreover, the files I copied have disappeared from the folder.
  • 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.
  • Sorry, I don't quite understand what you want me to do: should I copy the files with shortened names to my zotero storage folder, then reset sync by uploading to the server?
  • 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.
  • And to that I'll add saving the file to both the root directory and the Desktop on the local hard drive (i.e., C:\) rather than the network share.
  • 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.
  • Right, I understand. As you said, copying to C: is no problem at all. I just tried. I think the problem with saving to the network share has to do with file name length, because some of them, with shorter names, do copy. I'll experiment a bit more in my lunch break. I'll let you know.
  • 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.
  • Do you happen to know anything more about the network share? Server type (Windows Server, NAS)? Filesystem?
  • 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).
  • It's Novell Netware with NWFS. Files with names of a 125 character or longer do not copy. That makes the whole path name 198 characters. Does that make sense?
  • 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.
  • Yes, that worked. Thank you very much. Is there anything I can do to help you locate the cause of the limitation?
  • 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 got the 198 by adding the path length of the deepest directory to where the file would copy and the length of the file name. The PNESTQMM directory was a few levels deeper. In fact, is it significant that the first level to where the file could not be copied was the profile directory itself?
  • 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.
  • Yes, it's the path name length. I checked at the root level and two directories below that. At each level the maximum total path name length is 216
  • 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.
  • Okay, thanks for all your help. If there's anything else you want me to check, just let me know.
  • 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.
  • edited April 18, 2010
    ajlyon: Take a look at Q3VRT9W6 on the other machine. In your case there's an exceptionally long directory (with a gibberish name) involved, which is a case I hadn't tested for.
Sign In or Register to comment.