I have a problem applying the ‘compressed archive’ function: When I try it, I get the message:
‘Endnote cannot create or save this file. Make shure the disk You want to save the file on is not full, write protected or damaged.’ I made shure, the disk is neither full nor write protected or damaged. The error occured trying to store to various disks I tried.
The error even persists, if I choose just a single entry without any attachments to export.
An idea might be, there is a problem in the collaboration between endnot and windows 7?
I also cannot succesfully use the Endnote-Copy command. Endnote asks me where to store, but after answering to this question, Endnote doesn’t do anything, but also does not write an error message.
For the moment, I made a copy for backup purpose with the 7-Zip program.
My system: Endnote X4 on Windows 7 Pro 64bit, NTFS file system
The library contains 591 entries. The attachments comprise 672 files with a total of 1.4GB. The compressed 7z-file size is 1.2 GB.
I have had these errors too with X4. I have also had X4 create a compressed file, but then fail to be able to open it, expecially if it is being openned in a deeper folder.
If there are long file names, and folder names due to PDFs, I find the compress doesn’t always work. - X6 tries to rename the PDF subfolders I think, to help, but it only goes so far.
If I am copying the library, it can take a long time, and so I try going to lunch and coming back later. If I close endnote prematurely, it can crash the program and I have to reboot. It copies and then indexes the PDFs. Failure to copy - with no apparent error message, also may be related to long file path+names.
You might ask tech support if they can look at a library (really need to look at the compressed .DATA folder) and perhaps have tools to recover a library with these kind of limitations.
Thank You Leanne, I find, Your suggestion points into the right direction: The generation of a “Compressed Library” as well as generation of a “Copy” does not work, if a total path length of 255 characters is exceeded.
In my case I have PDF-file names, that may have a length of about 120 characters: for example here is one this with 122 characters: Augustin_2008__Mineralogical_and_chemical_mass_changes_in_mafic_and_ultramafic_rocks_from_the_Logatchev_hydrothermal_field.pdf
Now ENDNOTE has the ‘phantastic’ idea, to create a hierarchy of subdirectories with an additional length of 136 characters,
The consequence is that Endnote cannot handle the path it has created itself.
That is a new issue of path-length problem, which is already known for a long time now. I geht he impression Thomson Reuters does not work on it ??? I think this is an important point, as it prohibits backups and this is a major risk for all of us !!!
As ENDNOTE already deviates from its strategy to repeat the full file name as directory name and instead truncates it adding a series of numbers, may they realized the problem, but just failed to resolve it as it’s just the calculating algorithm of ENDNOTE which calculates a wrong path length ?
Endnote needs a tool to run to shorten all the PDF and PDF folder names for existing libraries.
I guess that in X6 they have made a start, but it isn’t fixed quite yet. Any calculation obviously depends on the directory path too, so deciding to archive (and/or adding a date or something else to make it unique) could be enough to push new files over the limit.
Yes Leanne, You are right. The tool for shortening the paths for existing libraries, You suggest, would be essential to allow backups of already existing libraries. The paths are created by the program ENDNOTE and stored witin the *.ENL file. So this new tool would have to read the ENL-File, to change it and simultanously it would have to work on the file directory to change the paths to the attached files.
Further, I think it is obvious, that ENDNOTE should take better care of the path’s lengths. In the example I presented, You see, that more than of the path length was added by ENDNOTE. That resulted from their strategy, to create three stacked levels of subdirectories
by 6 characters. That leeds me to the idea, that ENDNOTE already has realized, the PATH otherwise would become too long. But unfortunately ENDNOTE should have shortened it by 3 more characters to stay below a final path length of 255 characters. Exactly the same happens in several other examples. So I guess, ENDNOTE fails to calculate correctly.
I see two optional strategies for ENDNOTE to solve this urgent problem:
ENDNOTE could calculate correctly the path-length it creates and truncate the path at an appropriate point. It might be helpfull to abandon the third subdirectory level. (Remember ENDNOTE generates this path !!!)
ENDNOTE generally is able to handle path length of more than 255 characters. But it fails in the moment, when it tries to copy these paths. So ENDNOTE could be enabled to handle a path longer than 255 characters also in copying. That might work if it would use its own copy command (like several other software tools) instead of using that one of the system. Further it should use a compress-algorithm like 7z instead of the old zip to be able to handle archive files bigger than 2GB.