Add option to 'move' rather than 'copy' with file organizer
While I love file organizer, I would very much welcome having the option to move the auto-filed file, rather than copy it. With this I can automatically clear out folders by importing files, rather than having to double check that each file has been imported-copied before deleting it.
anonymous
shared this idea
This has been brought up with our Development Team and added to a few other tickets we have for improvements to the ‘File Organizer’
24 comments
-
Domenico
commented
It is a very important option.
-
Paul
commented
Thanks for adding different keys (Delete/Shift+Delete) for suppressing files from collection/entire library. Please do the same for dragging an entry between two collections (e.g. mouse shift) or copying it (e.g. shift + mouse shift) as users are asking in this thread. I would really appreciate it...
-
RobH
commented
I agree with one of the comments here, move when dragged, copy wich ctrl+drag
-
Lani
commented
Mendeley team, at least offer this as an *option*. In the meantime, the way I deal with it is that I download all my docs to a folder that I keep clean by deleting the original files after I have renamed them with Mendeley and checked the validity of the metadata.
To JiE, Al_Kohoul, and fernandoricardosantos: the way to avoid the unwanted copying of the citation in multiple collections in the library is to move the citation in Mendeley Desktop back into the "Unsorted" folder and then into the collection you want. It's annoying but it works. I can't understand why Mendeley copies into multiple collections...that's the way tags work. I would expect "collections" to behave like folders and not tags.
-
Matt Bernius commented
Robert,
Two use issues with this:
(1) as I mentioned there's the "naming" problem... The issue is that so many journals, even those who use good meta-data, still use wonky filenaming conventions (if we're lucky it's just DOI). So this quickly lets things get out of sync -- I'm right now suffering through this -- I ended up with a lot of duplication that I'm currently attempting to deal with.
Perhaps one answer would be a pop-up intervention to ask the user if they'd like to delete the first file *after* import (perhaps with the option to "remember" the decision in the future). A corresponding check-box could be added to the "file organization" page under settings.
As far as the second point (that Mendeley will move the file when it's inside the hierarchy) -- while this is the right way of handling it, I'm frustrated that the only way I can find to trigger the "auto-organize" event once a file is insider of Mendeley is to "reimport/attach" the file.
Let me layout the case I just tested this with (Windows Desktop app, 0.9.9r3.4x -- btw, consider adding a button on the about page to copy version number to the clipboard):
I attached a PDF of an edited volume (collier and ong's Global Assemblages) to my libarary. I had correctly updated my entry to list Collier and Ong as editors, not authors, so the author field was blank/unknown. The result was a file that was labeled - "Unknown - 2005 - Global assemblages technology, politics, and ethics as anthropological problems.pdf"
(aside: I've put in a request for a fallback rule for this case here: http://feedback.mendeley.com/forums/4941-mendeley-feedback/suggestions/140980-improve-file-organizer-with-more-metadata-groups-)
So, to make my life easier for the moment, I decided to add Collier and Ong to the author field. However, even after this major change, the file name remained the same, and the file remained incorrectly sorted in "unknown."
Opening the pdf within Mendeley did not trigger a review to see if the organization was in sync with the entry.
Choosing "Add File..." corrected the name and the organization, but added a second "ghost" file entry ("Files:" now listed 2 "collier-ong ...pdf"s). Thankfully, deleting the ghost did not delete the PDF from the directory.
BTW robert -- I know I've been submitting a lot of stuff as of late. I really do like Mendeley and want to support a smaller company (versus Thompson) -- it's just some of this UX stuff is really slowing down my overall resaerch and library organization process.
-
Robert Knight
commented
Hello Matt,
If the PDF file is already in the file organizer folder, Mendeley will move it rather than copying it. If the PDF file is outside the file organizer folder, Mendeley will copy it into the file organizer folder.
The reason Mendeley copies files from outside the organizer folder rather than moving them is mainly because we were wary of users accidentally messing up their existing PDF collections. Once you designate a folder as the file organizer folder, Mendeley 'owns' that folder and will move files around as necessary.
-
+1 Though I have no votes left. There's at least one really important reasons for adding this option for "watch folders" or when manually importing:
Incorrectly named pdfs with bad or not meta-data
When the PDF get's imported by the file organizer and correctly named (if all goes well). I end up with one well named and sorted file, and an ambiguously named file that remains in the watch folder. When I'm in a download mode, I can grab a lot of stuff and things can go out of sync fast.
The net result is a perpetuation of correctly and incorrectly named files. Moving that file would cut off the last step.
Related workflow question:
1. badly named, pdf with no metadata is ingested.
2. It gets misfiled and auto organized into the "unknown" folder.
3. I find the entry and correct it. Does the pdf file get renamed with the correction (with all the jazz, new folder potentially being created)? And if so does that create a new file insider the Mendeley folder? And if so, does the intermediary file still stay in the unknown directory?If that's the case, then that should be addressed as well.
-
Carl Anderson
commented
I still haven't entirely figured out how placing/moving entries around in groups affects file placement/movement! It seems like things that go into "Groups" somehow get treated differently than things that go into folders of "My Library". This seems to have weird effects in some cases; for example, I can set a folder in my library to sync files over the 'Net, but I can't do this for a public Group that I have created and own. This means that I need to create a separate "Topic X" folder in "My Library" and "Topic X" Group, then try to manually ensure that I add appropriate entries to both the folder and the Group (in order to ensure 1) files associated with a new entry are sync'd for my own use via the folder, and 2) entries added to the group are visible to other members). Rather cumbersome ....
-
Miguel Gaspar
commented
I would suggest you take a look at another favourite of mine -- MusicBrainz Picard -- which let's the user efficiently tag and sort music files. Could we have the possibility to pick a folder and move selected files over there (eventually with sub-folder structure and renaming), updating the database? If they are just moved, how shall I find the original (differently named) files to remove them?
(I also never understood which of my files not are going to be moved, sync'd, etc) -
sal
commented
Please fix this. it is so confusing!
-
Katrien
commented
please let us choose if we want to "delete file from current folder" or "remove file from all folders"!
that would be extremely helpfull
I spend quite some time figuring out why so many of my references had disappeard into the trash bin... ;-) -
JiE
commented
I would like to remind the original topic File Organizer.
The file organizer is a bit troublesome because once you check files to be organized, you can't return File links to their original location. If there is a way to get links back to the starting setting (original file locations), please share this info.
-
JiE
commented
Thanks Robert for making that part clear.
Please take a look at the problem of deleting one doc from all collections instead of only the selected collection.
-
Robert Knight
commented
@JiE
I think what is happening is that when you 'Delete the document' you are putting it in the Trash. When you re-import the document, Mendeley is digging your existing document out of the 'Trash' instead of importing the metadata afresh. When a document is moved into or out of the trash it retains its association with any collection it is in. This is so that if you accidentally move a document to the trash and then go and restore it, it appears back in the same collections that it used to be in.
-
JiE
commented
True.
#1 Collection 1. -> copy doc to Collection 2 (by drag drop)
#2 Deleting a document from Collection 2 will delete it from Collection 1.
BUT.
#3 Adding Document from file (the very same) manually back to Collection 2 will create a copy to Collection 1.
It Seems that the DB entry exists but the the front end entry (of Collection 1) is deleted in case #1. So. It is there but we can't see it.
MENDELEY HELP!
-
Al_Kohoul
commented
fernandoricardosantos, you spotted an ENORMOUS bug FOUR months ago, and it has not been solved yet! I just sent an e-mail to support about this:
"a. When "moving" a document between two collections, the document is merely copied.
b. When deleting the document (the one we intended to move), both documents are deleted. That is, the one we really wanted to delete, but also the one we had copied previously, in the other collection.
c. When moving a document from the trash to a collection (undelete), the document appears to that collection, but also to the other collection as in b).
d. I tried to copy a document to four different collections. We I delete it in one collection, they are deleted from all four collections. When I move it back from the trash to a single location, it is moved back to all four collection.This is a serious bug and Mendeley is unusable as it is. "
-
fernandoricardosantos
commented
This would be very helpful. Perhaps it could work like Windows: drag-and-drop to move; ctrl+drag-and-drop to copy.
I have also noticed that if I copy a paper from collection 1 to collection 2 and then delete the entry on collection 1 (which would be the equivalent of moving, but with all the added work...) -- the entry will desappear altogether from the library including the newly copied location (collection 2).
-
shqckr
commented
Is anyone on this topic having problems with the attached file link being lost when any option of File Organizer is chosen? It keeps happening to me when any File Organizer option is selected.
-
Oleksandr Voznyy
commented
I still don't understand what was the reasoning to make it Copy (instead of Move) in the first place.
And I'm surprised that it still wasn't fixed after so many time and complaints. -
sjakub
commented
It is surprising that this option is not there...
