Attached file delete and rename functionality

[ajbelle]

@koppor asked me to log an issue (feature request?) covering the "Delete" functionality currently available through the "Rename files" plugin https://sourceforge.net/p/jabref/discussion/318824/thread/8f56b49a/ Apparently plugins will not operate after JabRef 2.80 :-( While deleting attached files using the current plugin has the risks listed in the discussion, the manual alternative is a PIA making it "Attached File Delete" important if using JabRef as a literature repository manager, especially if merging files form existing repositories (e.g. EndNote).
It would be intuitively clear where to find what is to be deleted to have the delete button option listed in data entry tab via the exisiting hover over file 'right mouse button' menu containing “Open, Open Folder, Rename File, Move to file directory". .

It should add the following to what the "Rename files" plugin already does.

• Checks whether the file is required by another entry and ask if deletion is still needed!
• Present a large Warning that is has no way of knowing if other .bib files link to the files selected for deletion. Or have the ability to add a list BIB files (say in preferences) for checking and to check them for file links in the background.
• Warn that deletion is immediate and permanent with no move to "Trash" and there is no . Better still move the file to a "deleted file folder", making cross-platform implementation of safety net easier.
• Selecting files by highlighting entries for deletion when multiple files attached exist.
• If it does not delete it should not automatically remove the link, or must warn that deletion was unsuccessful.
• Have an option to "open containing folder" like PDF-XChange when deleting to manually check and clean up if desired (Endnote creates redundent folders that require deleting also).
• Make it work for files linked through "Legacy file Fields". I notice that ""Move to file directory" is currently unable to negotiate the legacy settings for my configuration E:\CRC Share\registry\endnote\the.Data\PDF\
• It could be made "Enable at own risk" in setting so users don't use it without realising and tarnishing JabRefs excellent reliability reputation.
  I know that is a lot of programming, but would make Jabref much more capable for repository management.

[simonharrer]

In the current master branch, there is a "delete local file" action attached to the right-click menu in the generals tab for each file.

[jhshinn]

It would be great if a shortcut key is assigned for the "delete local file" function.

[ajbelle]

I downloaded JabRev3.0 to check simonharrer's post (I was on Ver2.10. Yes it works as indicated. The multiple selection items in my original post are not relevant to this this solution. It does however delete without warning, without a backup copy and no copy in the recycle bin (but undo button does bring back the link :-). It doesn't worry me, but others could lose files without even realising (tarnishing Jabref’s excellent reputation). A shortcut key is assigned for the "delete local file" as proposed by jhshinn if implemented should require enabling by the user or a big warning must appear when it is attempted IMHO. Without the file being retrievable from a deleted folder it is too dangerous.

Item 7 "negotiating Legacy file Fields". is still a concern to me, and JabRev3.0 seems to have removed them completely, even though I still use them in my extensive and heterogeneous repository. The implemented "delete local file" action correctly negotiates links like (A01)BaiK_Invited-1302481664(A01)BaiK_Invited - Copy.pdf, but the "Open Folder", "Move, Rename File" and "Move to File Directory" still do not. The "Open Folder" goes to the user default directory and the other's return a 'Could not find file '...'. error message.

Thanks to the team for getting the functionality I asked for carried across.

[stefan-kolb]

I implemented most of the suggestions. The idea that a file should not be deleted when it is linked anywhere is omitted right now. We cannot check if it is in use in another bib file and I think the case were it is linked to other entries in the same file is rather seldom.