12-14-2010 02:17 PM
12-15-2010 03:23 AM - edited 12-15-2010 03:25 AM
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).
12-15-2010 04:18 AM
12-15-2010 10:06 AM - edited 12-15-2010 10:44 AM
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:
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.
12-16-2010 06:02 AM - edited 12-16-2010 06:11 AM
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.
12-19-2010 09:07 AM
I would appreciate, if someone of the Thomson Reuters people or one of the insiders here could comment on my analysis.
12-23-2010 11:17 AM
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?
01-03-2011 07:11 AM
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.
01-10-2011 12:48 PM
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.