The automatic file rename (under quality/entry cleanup) breaks the link to the file if renaming fails (e.g. because the new file name is too long and the OS keeps the originial name). I suggest to double check if renaming succeeded, before changing the link to the new filename. If not, a warning should be issued.
Going further, I would welcome additional formatters that allow to format the target name in a way to fulfill the requirements from the file system (a simple formatter would allow to truncate the title to a fixed number of characters).
I looked a bit closer into this problem and found that the link to the attached file gets broken when the file is actually an entry in a sharepoint data base which is synchronized to the file system for off-line use (OS is Win10 in my case). Due to the unspecified delay for synchronizsation, the only quick fix of the problem is probably a formatter for truncating the destination name of the file for automatic file rename.
Sorry for being not very specific in my previous entry.
I currently don’t have the time to analyze if there is something wrong with our code or not. Checking whether the renaming succeeded or not should be possible (but I think this is already implemented…).
I’m not using Sharepoint and I don’t really understand what the problem is if Sharepoint is used. You are linking to file name “file.pdf” which is synchronized using Sharepoint - then you try to rename it to “otherFilename.pdf” using JabRef.
Does the renaming fail at this point? Or does it work, but Sharepoint resets the filename some time later?
Regarding your second suggestion: [quote=“helgri, post:1, topic:63”]
format the target name in a way to fulfill the requirements from the file system
[/quote]
This is hard! Each file system has different requirements regarding allowed characters, maximum length, etc. However, as you proposed a formatter truncating a lengthy file name after X characters should be possible.
Dear Matthias, thanks for looking into this.
I also believe that the success of file rename is already checked and it works for me with Win10 and the NTFS file system. I am not a SharePoint expert but as far as I understood SharePoint requires that filenames obey URL naming restrictions since the names can be part of the URLs. This means that names accepted for an NTFS file system are not allowed for SharePoint which might lead to conflicts if a SharePoint document library is syncronized onto the file system for offline use. If a valid name is changed into an invalid name the sync mechanism automatically resets the old name (as it seems after Jabref has checked that rename succeeded). Most significantly, SharePoint requires names not to exceed 128 characters which is excceded frequently if the title of a paper is part of the name.
I understandd that an elegant solution of this problem is not easy, therefore a simple formatter that just allows to truncate the new name to a fixed maximum number of characters is probably the best solution for the time being. In addition I’d suggest to introduce a user defined sequence that is appended to the shortened name to indicate shortening (e.g. ’ . . . ’ or something similar, ‘…’ is again not allowed for SharePoint).
I use an extended version, employing the Replace command with a regular expression to shorten the title to the first 100 characters and adding some dots at the end to indicate truncation.
I did not succeed in applying the Replace formatter to the complete name incuding the bibtexkey which would allow to truncate the full target name to a fixed number of characters (e.g. 128 characters), even for very long bibtexkeys. I’d appreciate any suggestions how to apply the Replace formatter to the complete name.