I don't know if something's seriously wrong with my two computers or what. I managed to reproduce the dropboxifier deleting files bug, even after restarting the program, but now it just works properly. I'm including the notes below in case they're
of any help, but they might or might not work. I have a suspicion that it's partly Dropbox related. When you move files bit too quickly for dropbox to react properly it might temporarily re-add a folder that you just seconds ago had deleted (meaning the information
about file deletion hadn't reached the server before it attempts to update the file list on which the recently deleted file still exists). Then if a hasty user (cough cough) notices that he made a typo while writing the entry name, quickly undropboxifies the
stuff and re-adds them with the same name there might be a slight chance for a conflict. But to generalize it as much as possible: Some parts of the process seem to get in some faulty state at times due to some accessibility errors.
Not sure if that's the case or what. Anyway.. The files will be deleted if the link is missing and you undropboxify.
That's only thing that's easy to reproduce. :)
1) Dropboxify something, 2) remove link 3) Undropboxify it. (Doesn't matter if the Dropboxifier has been restarted or that it recognizes them as unresolved)
4) No files.
Here are the notes. I'll post again once and if I've got something actually valid.. These steps might help in noticing some loop holes though, if not that, then maybe some material for assertions, added security etc. :S
I did some testing and managed to destroy contents a few time and indeed, it does seem to involve a rare occurence where windows refuses to remove an empty folder ("cannot remove directory because it's not empty", there were other folders within folders
though in that particular case) or if there's a file in use at the time of copying.
1. Open a random file in folder to be Dropboxified
2. Write the Name ("Lost Horizon Saves") and find the source ("C:\Users\User name\Documents\Lost Horizon")
4. Receive an error that the file is in use.
5. Close the dialog box and the opened file.
Meanwhile in background the files are moved to Dropbox folder anyway, leaving the original folder (in documents) empty and unlinked. At this point (at least) two paths are possible.
a) Press Dropboxify button again and answer yes to overwriting the files in the Dropbox. Well, this does exactly that and it removes the original folder (not linking it) and it also empties the dropbox folder. Entry is shown as unresolved in the "Dropboxified
folders" view. If user now selects Undropboxify, the folder and the entry are removed and the original folder (in documents) is not restored. Data is lost (unless Dropbox managed to upload the files)
b 1) Whoops. The user notices that the files are moved and moves them back to the original folder in documents. He even removes the folder from saves that the Dropboxifier had made (so he can skip the dialog box about "overwriting files", if he doesn't remove
the folder, there's an error about "Could not find a part of the path 'D:\Dropbox\Saves\Lost Horizon Saves\2011-03-27_22-16_50IR6.sav'." Files are moved properly on second click though.)
b 2) He sees that Dropboxifier still remembers the given entry name ("Lost Horizon Saves") and the path where the files are located ("C:\Users\User name\Documents\Lost Horizon") on the left side and there's nothing suspicious on the right, so he presses
Dropboxify again. Then happens the following
b 3) User is greeted with message: "C:\Users\User name\Lost Horizon refers to a location that is unavailable. It could be on a hard drive on this computer, or on a network. Check to make sure that the disk is properly inserted, or that you are connected
to the Internet or your network, and then try again. If it still cannot be located, the information might have been moved to a different location.". Also at the same time, the original folder is gone again. No link.
b 4) User clicks ok and sees an unresolved entry in Dropboxifier with the info he had inputted. Now s/he can make a few choices.
He can try :
- Merging: Won't work since the folder is missing and if he creates it and selects that folder, then error message says "Target is a folder, not link. Entry removed." (or similar) and the entry is removed from the Dropboxified folders view. Now he should
move the files back to original location and try again more successfully. Unless of course, s/he's smart and manually creates the link into original location pointing to the correct Dropboxified folder (with original name). Dropboxify doesn't update its unresolved
status until restart, but at least notices that the situation doesn't require resolving anymore.
- Deleting and Linking: Best option to redeem the situation, if the user recreates an empty folder of the same name and place as the original folder. If no folder is created, file dialog tries to enter the non-existent folder (prompting an error message).
Anyway, after the confirmation dialog box the situation is fixed and the link and the files are safe.
- Undropboxifying: Worst option. Regardless of whether or not the original folder exists the files are removed from Dropbox along with the entry in dropboxifier. They're not returned to the original location, but instead are lost in the bitstream.
Anyway, that's at least part of the problem step-by-stepped. I managed to get messed up folder name again earlier, but it didn't occur this time. As I only noticed it afterwards.