This project is read-only.

Strange behaviour with folders and links

Jul 18, 2011 at 2:46 PM

I somehow managed to totally mess up my folders and links (nothing irredeemable, apart from one fairly unadvanced Minecraft save). I added a few save game folders within my Documents folder at first and one in Public\Public Documents following the instructions on this page. Everything seemed fine and they were marked as green each.

Then I scourged through the Users\<username>\AppData for additional save games and for some reason they did the same as if I wasn't using the program with admin rights (i.e. moved and not linking), although I was. As I proceeded to "Undropboxify" the minecraft saves I then managed to delete them because they didn't get moved back to the source folder and thanks to the little checkbox "delete in dropbox folder" (or such) the folder was removed from dropbox too. (might be a good idea to make sure that files were moved before deleting). I tried it a few times more (being more careful this time) and the same thing happened again and again. I was a little bit perplexed by this so I didn't try it out again with the normal folders to see if it was completely broken.

Anyway, at this point I proceeded to restarting the program to see if I was actually running it with admin rights (indeed I was) when I noticed that a few of the old folders (previously green) were shown as red. I went to check the folders and oddly enough some of them were named with the name I had named them when I was dropboxifying them and not the original folder name as it should have been (e.g. my "Documents\My Games\" folder was renamed to "Documents\My Games in Documents\" instead). Then again, some folders (like the stalker-shoc in my public documents and Egosoft) were named properly.

The concept of the program is awesome (I actually thought of implementing the idea myself, but found out that the wheel was already being invented), but I'll wait for a bit more stable release. :)

Jul 18, 2011 at 10:16 PM

Did some testing on my home desktop and I couldn't reproduce the issue. I'll keep a lookout though and report if I get something reproducible.

Jul 19, 2011 at 5:42 AM
Edited Jul 19, 2011 at 5:45 AM

Did you have DropboxifierLinks.xml open at the time or two instances of the application running somehow? Stepping through I can't see any case where what you described can happen - specifically losing data upon undropboxifying. If the copy back to source fails an exception gets thrown and the whole thing bails out.

Would be interested to see if there are reliable repro steps, as that would be a critical bug to fix.

EDIT - also don't forget that if your data was uploaded to Dropbox, it can be recovered from your Dropbox home. Dropbox maintains file history for 30 days, just go to the Dropbox website and click "show deleted files" and you will be able to recover from there.

Jul 19, 2011 at 8:52 PM

 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")

3. Dropboxify!

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.

Jul 20, 2011 at 5:50 PM

I think I understand where the problem is occurring. I'm going to do two things:

- If moving the files fails for any reason, move any moved files back to where they were and remove any linked entry. This is a nasty bug :(

- If source link does not exist when undropboxifying, move files to their place anyway. This was initially by design (it assumed you had removed the link intentionally thus you wanted to delete the files) but you have shown me the error of my ways, especially if something else goes wrong in the process.

Jul 20, 2011 at 6:31 PM

I've released a new version (0.1.7) that should hopefully stop any unintentional loss of data when things go wrong in the way you pointed out.

Thanks so much for your detailed report. If you find any other issues or my fixes don't work for you please let me know!

Jul 21, 2011 at 5:20 PM

Alright, I'll grab the new version. It's really a useful program. I'll let you know if something comes up!

Jul 21, 2011 at 5:40 PM

Alright, tried it out quickly and it didn't delete stuff anymore. Thank you. :) Three things I noted:

  • Strangely when after removing the link I undropboxified files successfully and re-dropboxified them into a folder of the same name it showed an exclamation mark and didn't create the link, but after ud:ing (== undropboxifying, too long word ;) and re-ud:ing them it got fixed.
  • If I removed the link and made it a directory instead, program noticed this, removed the entry and told me to manually merge them. Nice.
  • Then, there's still the small bug (or a feature?) where, if the directory in the DBify-folder already exists, it says it can't find the path and I have to press the db-button again to fix the situation. But that's unlikely and non-critical, unless the user manually moves them and forgets to delete the folder.

Over and out.