Moving files outside of Sandboxie and opening them still runs them in Sandboxie (impossible to fix without a restart)

[Tester100]

Hello! There has been a weird observation that I made where I haven't been sure if it's intended or not, so that's why I'm posting this. It looks like a bug for me. Whenever I move newly created files in Sandboxie's content folder outside of it, and I run these files, these are kinda forced-opened in Sandboxie and there is no way I can prevent this, unless I restart my system. Then it's normal again and programs or files will run just normally without Sandboxie. I should also note that when I move files inside Sandboxie that had been previously running, and it's a program and I'm trying to view its path in Windows task manager, I'm getting this error message: "Windows cannot find [path]. Make sure you typed the name correctly, and then try again."

How to reproduce the forced-Sandbox behavior:
- Download Firefox Portable, copy it into the Sandbox folder and run it sandboxed. As soon as all files are unpacked, move the Firefox Portable folder outside the sandbox and run the program. It will automatically run in Sandboxie. Viewing the process properties in Windows Task Manager results in the mentioned error message. This can only be avoided by restarting the system, or copying all required files and folders. Copying them is no option for really huge directories and files.

The opposite way:
- Launch a program, for example another portable program, close it again and then move it into the sandbox folder. Running it will work, but results in the same error message in the Task Manager again. Interesting observation: It allows to run Chrome and certain applications that use Chromium without any issue (due to its own sandbox).

Why is this a problem? Sometimes there are cases where it's necessary to launch a program without Sandboxie, for example when it needs to load a driver. Or the program has issues with certain tasks, but you normally want to run it Sandboxie, but sometimes you just can't. Having to restart the system or copying the whole (huge) directories are both tedious workarounds.

This problem happened on Windows 7 and Windows 8.1 every single time, but interestingly not on Windows 10. I hope you will be able to verify this. What can be done about this issue? Thanks in advance!

Additional info: I was able to verify this with Sandboxie 5.20, and it shows the same behavior even with old versions such as 3.76. Also confirmed this in a virtual machine which barely has any conflicting software, so no anti virus software or such programs.

[Bertus]

If you want to launch a program outside the sandbox, you can temporally disable sandboxie by choosing "disable forced programs".

[Syrinx]

This has been discussed elsewhere before and I believe the final conclusion was that it was a windows path related quirk but not a bug specific to sandboxie.

viewtopic.php?p=110136

For some reason, when Windows sends us the notification of a process starting, it is giving us the old file path.

[Tester100]

Thanks for your responses!

If you want to launch a program outside the sandbox, you can temporally disable sandboxie by choosing "disable forced programs".

The irony is, it's the free version, not the paid one. This is some kind of file path glitch.

This has been discussed elsewhere before and I believe the final conclusion was that it was a windows path related quirk but not a bug specific to sandboxie.
viewtopic.php?p=110136

For some reason, when Windows sends us the notification of a process starting, it is giving us the old file path.

Thanks, I had been unable to find that with the search, seems like I used the wrong words. That thread makes it sound like there will be no fix in the near future, and also no clear answer how and why Windows does that. Fact is, in my tests it happened on Windows 7 and Windows 8.1, both 64 bit and clean. But not on Windows 10, recently tested with version 1703. Might seem like a reason to switch to Windows 10, but at the same time Microsoft loves to break Sandboxie with every major upgrade, and that's every half year...
So, I can also confirm that copying the affected files and folders works around that bug, but this is too extreme with huge amounts of data. If we can't hope for a bug fix, what do you think is the best way to get around this path error without having to wait forever or killing your hard drives? Please tell me your suggestions if you got any!

[Tester100]

So, I have found a workaround. Making a hard link copy of the whole directory with the help of HardLinkShellExt and deleting the original folder works, and all files are still fine, without doing real disk-intensive copies.

1. Install Link Shell Extension. You can get it here: http://schinagl.priv.at/nt/hardlinkshel ... nsion.html
2. When you are done with the installation and the required Windows Explorer restart, right click the desired folder and choose "Pick Link Source".
3. Now head to the destination folder and right click there as well. Select "Drop As..." and then "Hardlink Clone".
4. Done! Better check the newly created hard linked files by rightclicking them again and choose "Properties". There is a new column for hard- and symbolic links. If it went well, you can see two paths for that file. Delete the folder in the original location, and hard linked files in the newly created directory won't show a red shortcut arrow anymore. Because these are treated as the original files now, as there is just a single hard link pointing to the data on the disk (zero hard links would mean the file is gone).

An alternative which doesn't require you to install anything is to make use of HardLinksShellExt's commandline utility called ls.exe. It's available on this page from the same author: http://schinagl.priv.at/nt/ln/ln.html

Once you are done with extracting the archive file, open up a commandline window and switch to its directory by typing
cd C:\YourPathHere\ln
Now you are able to enter the command for copying the directory. The syntax is as follows:

ln --recursive C:\dir\Sourcefolder C:\newlocation\Targetfolder

Compared to Link Shell Ext you have to create a new empty folder beforehand, or else all files and folders will be linked in the directory above. Unfortunately one drawback is that you won't be able to see a hard linked file with an icon.


Should someone find a better way to work around the Sandboxie Windows path bug or even find a fix, please let us know!