Full path length, too long for Microsoft generated by Endnote: It’s a problem, that is described through years in this forum for all Endnote versions since X1. But Thomson doesn’t make any efforts to discard it. In case of the default settings, Endnote generates it’s paths for attachments by nesting it into a file structure like C:\ ‘base_directory’ \ ‘name_of_data_base’.Data \ PDF \ ‘Endnote_generated_file_name’ \ ‘original_pdf_file_name.pdf’ The ‘original_pdf_file_name’ often is a bit lengthy because it serves to easily recognize its contents. So it might be a file_name like [author_year__paper_title] and easily might be 100 letters long. As Endnote generates a directory above it containing the original_filename plus an identification number, just the combination of subdirectory and filename expands to much more than 200 letters. Adding the superior directory names, also created by Endnote, we easily exceed path lengths of 250 and even more letters. And this is the point when Microsoft programs begin behave strange. Just copying the Database might truncate the filenames, might corrupt the PDF file etc. all kind of situations might occur, leaving the user in the situation not being able to continue to work with these files, often even not being able to open them. This was considered as annoying and problematic, it was reported by generations of users, but I didn’t find that Thompson has changed it policy or has given an advice except telling their customers to change their original file names before importing them with Endnote. Often this problem becomes obvious after hundreds of files are archived in the Endnote data base. Changing alle file names at the point of time is not an option, i find comfortable.
It isn’t realy a Problem if you use “Save a Copy” at Endnote->File (instead of manualy copying the .enl and .data),
as the Folder- and Filenames get shortened automaticaly if you copy it by that way into a longer filepath-structure.
I only have seen corrupted files because of manualy copying.
The only Problem you could have is if you have your DB on a Networkdrive. (I had a case were the pdf wasn’t created because the filepath would have been to long).
My source path and my target path are absolutely identical ! I’ve just moved the whole Endnote database to a different partition on the same internal hard disk due to limited space. The new path is exactly the same, as the old one, just on another internal drive - Y:\ instead of X:\. So there is absolutely no difference in path-length, because it is identical. I don’t understand, why Endnote creates path lengths that are too long to be copied by the native operation system’s own copy function. And I don’t understand how does it work, that a path can be created by Endnote but not be copied ? Is there no way to make Microsoft Windows XP move the whole path as it is ? And to top it all off: My backup-Software (Acronis) is not able to restore the backup-files in the Endnote generated PDF-directory. To backup the hard disk doesn’t give security for Endnote stored attachments. Backup solutions are preempted by Endnote ! I’ve moved my Literature.data, to a different drive, got corrupted file names, cannot get the backup-files from the backup software - so I guess it es lost. I think Endnote should realize there is a problem !
May be I understand a bit more meanwhile, while this doesn’t solve the issue:
The NTFS filesystem allows path lengths of about 32000 letters. So this is not the limit exceeded here.
But most Windows tools and programs expect length of the full path not to exceed approx. 255 letters. This is limit is caused by the size of the variable the Windows program reserves for the path. That is true for most applications as well as for commands like copy.
It is different for some programs able to handle full length paths like robocopy.exe from Microsoft.
It seems Endnote also is able to handle these long paths.
But almost all programs running in MS-Windows are not.
So each operation with the Literature.data directory created by Endnote is only possible with programs able to handle long path - that means nearly none of the typical programs like ‘copy’ or ‘Acrobat’ etc.
The consequence is: Only Endnote is able to deal with the subdirectory Literature.data
Many backup programs do not expect long filenames. That means restoring Endnote created ‘Literature.data’ from a file-system-backup is not possible.
The way to deal with it:
- Create a compressed library using the Endnote menu command combination FILE/COMPRESSED_LIBRARY to create a single file containing the whole data base and
- let this file be backed up by the back up software.
- Do not expect to restore the original PDF Files from the standard backup
May be someone of the Moderators of this forum might check if my ideas are right … and may be they offer a better solution for the future.
To make my long text short:
It seems the described problem occurs, because Endnote exploits the capacity of the NTFS file system in path length (may be also FAT32) to a degree, that is not reliably supported neither by the microsoft native programs like ‘copy’ nor by many other programs like ‘Adobe Acrobat’ or ‘Acronis’ backup software.
So handling the created attachment archive savely is only possible with Endnote itself.
That is not a typical behaviour of files. So it might be changed or the consequences should by announced more prominently to make the users aware of this pitfall.
I would appreciate, if someone of the Thomson Reuters people or one of the insiders here could comment on my analysis.
- How far am I right in my analysis ?
- Is there a better solution to deal with the problem than this workaround described by me ?
I haven’t yet given up to get a comment of one of the “Thomson Reuters” people.
This is really a forum for users to help users and not a correspondence medium for conversations with the developers. I agree (and I am just another user!) in your diagnosis and that they should be looking at the issue but doubt they will engage in a public conversation about an issue such as this. I suggest that if you want to influence developers handling of these kind of things, use the suggestions, and.or volunteer as a beta tester? or ask that if other users agree in a thread in the suggestions forum where users can “kudo” the suggestion?
Thank You, Leanne !
It’s always helpful, to get some guidance, how to use a forum in the right way, as I am not familiar with this forum.
I thought, developers of Endnote would also look here and engage themselves in the discussion, as they might learn, which features of the software create problems to the users. And in a discussion the core of this might be worked out best.
Leanne, as it seems You are used to talk to the developers, may be you could direct their attention also to this post, as it is an old issue, still unsolved.
If you need to have long filenames for the PDFs, I would recommend only sharing libraries with others using the .enlx compressed library format. That can be copied and pasted in Windows without any error, and maintains the groupings, filenames of the PDFs, etc. The best way to decompress it is in a short filepath directory (a location such as C:/decompress). If you need to share these libraries liver over a network, it is harder to control the length of the pathway obviously. Copying/pasting the .Data and .enl to the network or decompressing the .enlx file will not work if the server cannot handle the filename lengths.
You can use Long Path Tool as well, it works for such issues!
Well, you can use Long Path Tool for such issues, the tool works good.
I recomended u to use “Long Path Tool” program. i have similar problem and now its working for me :).
Have you tried the Long Path Tool. I’m sure, it will serve your purpose.
Take my advice and use (long_path_tool) for fast and easiest way to fix your problem.Let me know if i helped you.
If you are getting error saying path or file name are both too long,i suggest you to use (long_path_tool).I will for sure fix your problem and you will know in future what to use.