A game's uninstaller deleted my whole game folder, directed here by game site.

The uninstaller probably uses the "RMDir" NSIS command to remove a whole directory tree but why it ended up deleting too much is hard to say, maybe a bug in their uninstaller code?

You really have to report this type of bug to the people that created the game/game add-on...

I have no idea what Onverse is, nor if a Onverse skin is some sort of unofficial add-on but the point is still the same, we can probably not help you because it is likely a bug in this specific uninstaller and not really a problem with NSIS itself. (NSIS is a tool used to generate installers/uninstallers)

Something like this can happen if the uninstaller has been coded to execute "RMDir /r $instdir". $instdir is normally set to the path the uninstaller .exe is in but the developer could modify this path etc.

A developer should be careful when RMDir /r is used in a script because recursive delete can be dangerous but that does not mean there is a bug in NSIS itself, NSIS is just doing what the developer instructed it to do.

You could maybe try a free NTFS undelete tool to get some of your data back, I believe there is at least one such tool on sourceforge...

FreeRecover on sf.net but I have never used that one myself. There should be several tools to choose from, just google "ntfs undelete". I have used Recuva in the past and it worked perfectly...

MoonlightMaiden, those who directed you here are not correct. You can't not write an uninstaller and there's no such thing as a 'skin' (at least not in this context). NSIS is a scripting language - you write the code and compile it into an executable. If an uninstaller was coded by someone who knows what they're doing, it will delete only the files that were installed, no matter where they were installed. Like Anders said, this uninstaller probably just blindly deletes the whole folder with RMDir /r. Maybe they recycled someone else's poor code but anyhow, the responsibility is theirs.

Also, whichever file recovery sw you use (+1 Recuva), do it as soon as possible, because the longer you wait, the smaller the chance you'll be able to recover the files successfully. Don't copy/move/install anything on that drive and don't defrag it; if you're using some autodefrag sw, disable it immediately.

Thank you very much. Is it hard to use?

Another Mod at Onverse is still trying to clam it's my fault x.x


I told the Dev that directed me here this, since he's been the nicest so far, hopefully it'll get figured out.

Is it hard to use?

I think the only correct answer is - it depends. [Edit] If you were asking about Recuva - no, it's very simple.

Another Mod at Onverse is still trying to clam it's my fault x.x
http://forum.onverse.com/showpost.ph...7&postcount=17

The very fact that there is a default folder means you are given a choice. If you are given a choice, you can't be blamed for making it. I practically never install games to default locations. Properly written and tested installers won't have a problem with that. It's silly to assume all users will just click 'Next' and it's wrong to blame them for problems if they don't.

MoonlightMaiden, I tested the installer and these are the problems:
1) as we suspected, uninstaller obviously uses RMDir /r $INSTDIR. If you install to SomeDir\Onverse all is ok but if you install to SomeDir\ you will lose the entire contents of SomeDir upon uninstall. The proper and safe way is to use a series of Delete commands to remove the files, then RMDir commands to delete subfolders and finally RMDir $INSTDIR, without /r; that way the folder only gets deleted if it's empty.
2) installer seems to be missing the InstallDir attribute, because \Onverse doesn't get appended to path when user changes the install location. This is how you ended up with files installed to Games\ instead of Games\Onverse. This is a common mistake in installers where $INSTDIR is set with StrCpy, typically because they want to set the default instdir with regard to architecture ($PROGRAMFILES vs $PROGRAMFILES64) and wrongly assume InstallDir attribute is redundant. But this installer is x86 only so it's unclear why they're using StrCpy. Another sure sign that StrCpy is used is that the command line param /D= doesn't work (it's rarely taken into account). So, instead of StrCpy $INSTDIR "$PROGRAMFILES\Onverse" it should be InstallDir "$PROGRAMFILES\Onverse".
1) and 2) create a dangerous combination, as you have experienced. Forward this over there so they know what the problem is and how to fix it, and I'm certain they will, so they don't get more disgruntled users.

I let them know, but their refusing to admit it was their problem, even locked one of the threads. I got messaged by another player from the game and told me not to listen to anyone their, even the guides, so it sounds like this is more of a problem then they try to lead on. I wish I knew how to get them to fix it, I would hate for it to happen to anyone else. I have no idea who to contact though.

I was unable to recover the data, it was my fault though I'm afraid, I had forgotten I had done a defrag a couple days later, which someone later had reminded me of. It could have been worse though, at least it was just my gaming folder, and not family pictures or major system stuff.

Just leave it be, we did our best.

I read the reply you got and I can't leave it be. Quality software strives to minimize the chance of user screwing up. Not the case in this case. \Onverse not being appended automatically is an obvious flaw with a simple fix, as described earlier. As for updates, there's no reason why the patcher couldn't update the install log with the list of new files. It shouldn't involve a lot of extra coding and it doesn't require updating the (un)installer. And even that isn't absolutely necessary. IIRC, updates are saved to a subfolder, and it's relatively safe to delete whole subfolders; the worst thing that can happen is loss of user-generated files if any. What you never do if you care about good practices is recursively delete the base install dir.