Problem with OpenFilePath in 3.00.06
Moderator: Barb@Invincea
It seems that OpenFilePath=C:\Download\*.* is only a partial solution as it does not allow the creation of directories under the root! Oops. So it seems I'll have to go with OpenFilePath=C:\Download (no slash). This isn't exactly what I want since it opens up anything starting with Download (files or directories), but at least it works as expected.
Works for me:
Firefox set to save downloads to C:\Download
SB: OpenFilePath=C:\Download\
1st download of file winds-up in unsandboxed C:\Download
2nd download of same file also there, with (2) suffix added to filename
wraithdu test :
Created unsandboxed C:\Download\test.txt
Used sandboxed cmd to rename, to test2.txt
Result: test2.txt in unsandboxed C:\Download folder, as expected
Now if wraithdu will only confirm this, we can put it to rest as far as I'm concerned.
Firefox set to save downloads to C:\Download
SB: OpenFilePath=C:\Download\
1st download of file winds-up in unsandboxed C:\Download
2nd download of same file also there, with (2) suffix added to filename
wraithdu test :
Created unsandboxed C:\Download\test.txt
Used sandboxed cmd to rename, to test2.txt
Result: test2.txt in unsandboxed C:\Download folder, as expected
Now if wraithdu will only confirm this, we can put it to rest as far as I'm concerned.
XP Pro SP3
check the first suggestion again
I think it is as simple as the initial response, which is different than that posed by the original author:
TZuk notes that C:\download and c:\download\ and c:\download\* worked fine.
The issue may be simply that you need to add the base directory without the slash. No?
TZuk notes that C:\download and c:\download\ and c:\download\* worked fine.
The issue may be simply that you need to add the base directory without the slash. No?
Been busy. I will test shortly.
brrrknee - tzuk finally reproduced the problem, so it's not isolated. Removing the trailing slash, while it does work that way, is just a workaround. For example -
OpenFilePath=C:\test
will allow files to be written to c:\test, c:\test2, c:\test3, etc. and to a file named c:\test.txt, c:\test2.txt, etc. This is not the desired result.
OpenFilePath=C:\test\
will only allow files to be written to c:\test\ and subdirectories, but not any files named c:\test*
brrrknee - tzuk finally reproduced the problem, so it's not isolated. Removing the trailing slash, while it does work that way, is just a workaround. For example -
OpenFilePath=C:\test
will allow files to be written to c:\test, c:\test2, c:\test3, etc. and to a file named c:\test.txt, c:\test2.txt, etc. This is not the desired result.
OpenFilePath=C:\test\
will only allow files to be written to c:\test\ and subdirectories, but not any files named c:\test*
Minor problem... I just updated from 3.00.05 to 3.00.09. I have a "ClosedFilePath=F:\" directive in Sandboxie.ini to deny access to my F: partition, and with the new version I now get a "SBIE2307 Could not map drive F[C0000022]" error message.
The error only appears when I start a program sandboxed with Sandboxie Control running, or when I start Sandboxie Control with a sandboxed program running. It doesn't appear as long as Sandboxie Control isn't running, it doesn't show up in the System Protocol, and it doesn't seem to have any visible negative consequences (access to F: is denied as desired).
The error only appears when I start a program sandboxed with Sandboxie Control running, or when I start Sandboxie Control with a sandboxed program running. It doesn't appear as long as Sandboxie Control isn't running, it doesn't show up in the System Protocol, and it doesn't seem to have any visible negative consequences (access to F: is denied as desired).
Who is online
Users browsing this forum: No registered users and 1 guest