Sandboxie Forum - XxxFilePath for unavailable subst drive prevents prgm run (9710)

Mike:

Tue Mar 15, 2011 7:31 pm

Works beautifully in 3.53.07. Nice job, it's perfect now. :)

Mike:

Mon Mar 14, 2011 7:02 pm

]]>Quoting tzuk: ]]>Then when the power comes back on: drive D --> \Device\HarddiskVolume5 drive X --> still \Device\HarddiskVolume4\Test ]]> Interesting, never noticed that. Side note: Since the volume number can change so easily, anyone still using a hack like [url=http://www.sandboxie.com/phpbb/viewtopic.php?p=50160#50160]\Device*\HarddiskVolume1\[/url] to cancel the suffixing asterisk might want to switch over to the [url=http://www.sandboxie.com/phpbb/viewtopic.php?p=62186#62186]pipe operator[/url].

tzuk:

Mon Mar 14, 2011 4:52 pm

You're right, it does have to do with powering off the drive, or more specifically, the powering back on. I'm not sure if this method of powering on/off is specific to revoSleep 0.2.4 or if it is something in Windows that it uses. Anyway, when the drive comes back on, it is given a new internal name, which is different than the old path that Sandboxie recorded for the SUBST drive. For example, we start with, drive D --> \Device\HarddiskVolume4 drive X --> D:\Test --> \Device\HarddiskVolume4\Test Then when the power comes back on: drive D --> \Device\HarddiskVolume 5 drive X --> still \Device\HarddiskVolume 4 \Test Version 3.53.07 will fix this.

Mike:

Sat Mar 12, 2011 6:13 pm

If I only removed the drive letter in Disk Management, everything was perfect. Perhaps the problem is with the way I powered off the drive using [url=http://revosleep.realspooky.de/]revoSleep 0.2.4[/url]: ]]>Quoting http://revosleep.realspooky.de/: ]]>Here is the proceeding of revoSleep: - lock all partitions on the specified hard disk - dismount all partitions on the specified hard disk - sleep the specified hard disk - put all volumes on the specified hard disk in offline state (vista) - deactivate the driver for the specified hard disk - the locked drives won't wake up - u can unlock/lock different drives ]]>

tzuk:

Sat Mar 12, 2011 3:09 pm

I'm not sure if I saw that -- I believe for me stuff worked as expected while testing numerous unmount/remounts without restarting programs in the sandbox. But I will take another look.

Mike:

Sat Mar 12, 2011 12:32 am

Thanks for the improvement, tzuk, and sorry for the delayed reply. Everything works as expected, except when the drive is powered off in Step 2 of my Feb. 25 post. In that case, the first instance of Notepad can't access X: when D: is re-mounted, but the second instance can. Again though, I'm pretty happy with the current behavior.

tzuk:

Mon Mar 07, 2011 9:56 pm

Version 3.53.06 should fix the problem you reported Mike. Also this version should fix the problem where Windows Explorer did not detect drives being added or removed.

Mike:

Sun Feb 27, 2011 1:00 pm

No worries, I'm pretty happy with the current behavior. Thanks for the fix!

tzuk:

Sat Feb 26, 2011 10:03 pm

OK. I'm not sure this is easily fixable. I think I looked into a similar issue a few days ago with Explorer because I noticed it was not refreshing its list of available drives, as I was mounting/remounting some drives. It may have to do with Explorer relying on the Shell Hardware Notification service to refresh the list, and this service not notifying sandboxed programs. But I'm not sure. In any case it may be a more complicated issue that I might not be able to address immediately.

Mike:

Fri Feb 25, 2011 3:05 pm

Things seem to be working, although there may be a minor niggle. For the test below, D:\Test is mounted as subst drive X:\. I ran Notepad in two different sandboxes with a ReadFilePath=X:\. 1. Run Notepad in the first sandbox. 2. Dismount D:. 3. Run another instance of Notepad in the second sandbox. 4. Re-mount D:. 5. Issue: For me, X: is inaccessible to the second instance of Notepad, although it's accessible to the first instance. Error message: "X:\ is not accessible. The specified path is invalid." 6. If I exit the second instance of Notepad and run it again, then it can access X:. In Step 2, if D: is actually powered off instead of simply dismounted in Disk Management, then in Step 5 neither instance of Notepad can access X:. The first instance gives a different error though, saying that "X:\ refers to a location that is unavailable. ..."

tzuk:

Thu Feb 24, 2011 4:36 pm

This should be fixed in version 3.53.04.

Mike:

Sun Feb 13, 2011 12:46 pm

Ah, tzuk, I should have been more explicit. The case you presented above should work fine, I think. The problem occurs when dismounting the actual hard disk volume without first removing the subst virtual drive. For example: 1. subst X: D:\Test 2. XxxFilePath=X:\ 3. Sandboxie works fine. 4. Dismount D: without removing X:. 5. Sandboxie gives errors. 6. subst X: /d 7. Sandboxie is happy, works fine. In Step 5, the errors occur as soon as the drive letter is removed using [url=http://technet.microsoft.com/en-us/library/cc770943.aspx]Disk Management[/url] or a third-party util.

tzuk:

Sun Feb 13, 2011 11:50 am

So to test this, I am thinking -- 1. SUBST X: C:\TEST 2. Add some Sandboxie setting that includes drive X. 3. Run something sandboxed, should work. 4. SUBST X: /D 5. Run something sandboxed, should fail. Yes?

Mike:

Sun Feb 13, 2011 11:47 am

Hmm, I actually see no change in behavior with 3.53.01. The errors are triggered as soon as the "real" volume is dismounted.

tzuk:

Wed Feb 09, 2011 8:12 pm

Should be fixed in version 3.53.01.

Mike:

Mon Jan 10, 2011 4:15 pm

]]>Quoting tzuk: ]]>But here you got error "object path not found" and this is why the problem occurs. ]]> Oh, I see, because we're mapping a subfolder. ]]>Quoting tzuk: ]]>So this will have to wait for version 3.53. ]]> Great, thanks. Not an urgent issue.

tzuk:

Mon Jan 10, 2011 3:41 pm

Interesting. Sandboxie already ignores settings with drive names that it can't find, but is only prepared to handle the case where the error is "object name not found". ("Object" being the "X:" in this case.) But here you got error "object path not found" and this is why the problem occurs. I will revise Sandboxie for this but I'd rather not mess around with version 3.51 anymore, if I can help it ... So this will have to wait for version 3.53.

Mike: XxxFilePath for unavailable subst drive prevents prgm run

Mon Jan 10, 2011 1:50 am

Let's say I have a [url=http://technet.microsoft.com/en-us/library/bb491006.aspx]subst[/url] virtual drive, X. When X: becomes unavailable (after I dismount the corresponding hard drive), programs can no longer run in any sandbox with a ReadFilePath=X:\, OpenFilePath=X:\, or ClosedFilePath=X:\ setting. Basically, the errors come in threes: [code:1:21b9dac97e]SBIE1406 Missing or invalid expansion for (DOS path): [C000003A] SBIE1412 In text: [Sandbox05] ReadFilePath=X:\ SBIE1203 Cannot build path list (error in ReadFilePath)[/code:1:21b9dac97e] Can Sandboxie simply ignore unavailable drives, like Windows Explorer does? I'm using Sandboxie 3.51.11 on Windows 7 x64.