[FAQ] $RECYCLE.BIN subfolder in ReHIPS folder

Started by fixer, October 13, 2017, 09:26:45 PM

Previous topic - Next topic

fixer

As upcoming ReHIPS 2.3.0 release will have $RECYCLE.BIN subfolder, let me explain this one a bit.

Before reading this blogpost I recommend taking a look at previous blogposts about Copy User Data feature here https://forum.rehips.com/index.php?topic=9560.0 and Open File Access feature here https://forum.rehips.com/index.php?topic=9484.0

So as you already know isolated programs don't have any access to the real user profile folder. ReHIPS treats this folder as some kind of a sacred cow, it redirects any access to it into ReHIPS user profile folder. So even if Copy User Data is disabled, when the file is double clicked, it's still copied from real user profile folder into ReHIPS user profile folder for the Open File Access feature to work.

So when you double click on file C:\Users\UserMe\Desktop\MyTexts\ConquerTheWorld.txt, it's first copied into C:\Users\ReHIPSUser1\Desktop\MyTexts\ConquerTheWorld.txt, then permissions are granted (this step is done automatically as the file resides now in ReHIPS user profile and ReHIPS user has full access to it) and then this newly copied C:\Users\ReHIPSUser1\Desktop\MyTexts\ConquerTheWorld.txt is opened (this is done transparently, so the program may still think it's working with the original C:\Users\UserMe\Desktop\MyTexts\ConquerTheWorld.txt file). When the program is done working with the file, it's restored back to original location C:\Users\UserMe\Desktop\MyTexts\ConquerTheWorld.txt deleting the temporary C:\Users\ReHIPSUser1\Desktop\MyTexts\ConquerTheWorld.txt file.

After this long intoduction we're finally getting to the point of this blogpost. What if something goes wrong? For example user double clicks the file, but there already is a file with that name in ReHIPS user profile folder. We don't want to loose any files, that's where recycling comes into play. We should get rid of that existing file somehow, so we could copy the file from real user environment. But at the same time we should keep the file, just in case, who knows what is in it, maybe user deliberately put it there for safekeeping. I can already hear some of you say: delete it to the recycle bin, the file is deleted on one hand and it can always be restored if needed on the other. You're right, that's possible. But Recycle Bin can be full, disabled or who knows what else. And we can't afford to loose a file in any way. So we have another plan: we move this file to our improvised Recycle Bin in C:\ReHIPS\$RECYCLE.BIN folder.

But not just to the folder itself. Into the user subfolder which is named after real user SID. You can always get user SID running the following command in cmd.exe "wmic useraccount where name='your_real_user_name' get sid". Why these subfolders and not just put files to the $RECYCLE.BIN folder itself? Not to compromise confidentiality. You see, the files are moved from user profile folder. And this folder by definition contains files and folders only the owning user has access to. So we have to create a Recycle Bin section for the user only. By the way, default Recycle Bin operates the same way, though it's transparent for the end-user.

So basically $RECYCLE.BIN is just a simple folder. And it doesn't exist or it should always be empty should things go smoothly. But if something goes south, old files from ReHIPS user profile folder are not deleted, but instead moved to this folder appending date and time to their file names. Just in case. Maybe and hopefully you'll never need them. But if you had an important file in real user profile folder and you think that some changes to it are lost, check ReHIPS user profile folder first and then this C:\ReHIPS\$RECYCLE.BIN folder, and it'll be there for your serenity.