Problem with OpenFilePath in 3.00.06

wraithdu · Post by **wraithdu** » Mon Jul 30, 2007 12:26 am

I ran a trace for file, pipe, and ipc denied, and only got this when trying to save to the offending directory -

(003972) SBIE (FD) 00000001.0F.FFFFFFFF \Device\NamedPipe\srvsvc

PID 3972 is firefox.

EDIT - Eh, that's meaningless. I tried opening it with no effect.

Paul_K · Post by **Paul_K** » Mon Jul 30, 2007 9:39 am

wraithdu wrote:Can you confirm that
OpenFilePath=firefox.exe,C:\fxdownloads\*.*
saves files to the un-sandoxed (ie, real) directory?

Ok, I tried it and found that my download IS saved to the un-sandboxed folder if I use that line in my configuration file.
Without the *.* the download stays in the sandboxed folder.

Paul_K · Post by **Paul_K** » Mon Jul 30, 2007 9:55 am

This may be unrelated, and probably by design, but when I use the OpenFilePath method to save my downloads:
When the first download attempt leaves the file in the sandboxed folder, another immediate download attempt gives the following Sandboxie message after telling Firefox to save the file:

Firefox must not be able to "see" this downloaded file is already in the sandboxed folder, or else it would save the file with (2) appended to the name. It seems as if it really is looking at the un-sandboxed folder because it isn't changing the filename.

Ex: I downloaded CleanUp40.exe, and a second download attempt should have given me CleanUp40(2).exe in the downloads folder
Using the RecoverFolder method, I do get CleanUp40.exe and CleanUp40(2).exe in the sandboxed folder, awaiting Recover.
I think I'm going to save a copy of my .ini file and do a clean install of Sandboxie, just in case my last 2 installs over the previous version didn't work-out right.
*Edit* No difference after clean install

wraithdu · Post by **wraithdu** » Mon Jul 30, 2007 10:59 am

Paul_K, try this if you would.

OpenFilePath=C:\fxdownloads\

But instead of just clicking a download link, RIGHT-CLICK and SAVE LINK AS. See if that works. Also try out IE7, as I didn't have a problem using that browser at all.

This may solve the FF problem, but I'm still worried about my cmd.exe test a few posts back. I've now tried all this on a computer here at work that is a totally different setup than at home, and I get the same results.

tzuk · Post by **tzuk** » Mon Jul 30, 2007 11:04 am

Finally I can reproduce the problem...

This time I tried saving a download into

C:\Download

with

OpenFilePath=C:\Download\

And in fact I got files created in the sandbox, and some variation on the errors that Paul_K reports.

Unfortunately I don't have much time now, but I'll be looking deeper into this later.

SnDPhoenix · Post by **SnDPhoenix** » Mon Jul 30, 2007 11:16 am

And yet again, I am the only one who cant reproduce the problem(s), damn, I must have the most perfectly configured pc or something.

Paul_K · Post by **Paul_K** » Mon Jul 30, 2007 12:01 pm

wraithdu wrote:Paul_K, try this if you would.
OpenFilePath=C:\fxdownloads\

But instead of just clicking a download link, RIGHT-CLICK and SAVE LINK AS. See if that works. Also try out IE7, as I didn't have a problem using that browser at all.

As must have worked for you:
Rt-click and Save Link As does save the download in the un-sandboxed C:\FxDownloads folder with Firefox.

Downloading the file with IE7 worked fine, saving directly to the un-sandboxed folder.
So, is this a Firefox issue? I never used OpenFilePath for downloads, before, so I guess that's why I never saw it.

Paul_K · Post by **Paul_K** » Mon Jul 30, 2007 12:18 pm

SnDPhoenix wrote: I must have the most perfectly configured pc or something.

The rest of us can only aspire to reach the perfect configuration that you must have.
LOL

SBIE User · Post by **SBIE User** » Mon Jul 30, 2007 1:06 pm

tzuk wrote:Finally I can reproduce the problem... This time I tried saving a download into

C:\Download

with

OpenFilePath=C:\Download\

And in fact I got files created in the sandbox, and some variation on the errors that Paul_K reports.

Tzuk,

I've found that trailing slashes at the end of directory paths in some settings in the config file can sometimes cause problems.

So, based on my experience, entries like C:\Download and C:\Download\* usually (always?) work but entries with trailing slashes like C:\Download\ often do not work.

Does this help?

wraithdu · Post by **wraithdu** » Mon Jul 30, 2007 1:43 pm

At last, I'm not crazy

SBIE User - in my case I cannot get OpenFilePath=C:\Download\* to work either, only OpenFilePath=C:\Download\*.*

Another test for the rest of you to try -

1. Set OpenFilePath=C:\Download\ in INI (typed exactly that way with the trailing \ )
2. Create the C:\Download\ directory
3. Create a new test file inside called test.txt
4. Open a sandboxed instance of cmd.exe
5. Navigate to C:\Download\ and type 'ren test.txt test2.txt' (no quotes)

What should happen is the file should be renamed. What happens to me is that test.txt disappears from the real directory, and test2.txt appears in the sandbox. How bout the rest of you?

SBIE User · Post by **SBIE User** » Mon Jul 30, 2007 2:05 pm

wraith,

I'm sure you're not crazy, but I got different results.

I conducted your experiment exactly as you specified.

I created the C:\Download folder with Windows Explorer outside Sandbox. I then created the test.txt file with a couple of lines of text, again outside Sandbox.

I then opened cmd.exe as a Sandboxed program and renamed test.txt from the command line, as you specified. When I renamed test.txt to test2.txt, the change occured only in the regular, unsandboxed C:\Download folder and not in the Sandbox. That's the result we should get based on the OpenFilePath=C:\Download\ line in the config file. (The trailing slash did not cause a problem for me this time.)

I then checked my Sandbox folder and found that an empty folder for C:\Download had also been created in the Sandboxed environment when I created the folder for your experiment or when I operated on test.txt from the sandboxed command line. However, the sandboxed C:\Download directory was empty.

I don't understand why that new directory was ever created in the Sandboxed environment. I created it with Windows Explorer completely outside of Sandboxie and created the test.txt file outside of Sandboxie before I opened the cmd.exe window as a sandboxed instance and renamed the text file to test2.txt.

Any ideas about why the C:\Download directory showed up in my Sandbox environment?

Sorry I could not confirm your results. It remains a puzzle.

Paul_K · Post by **Paul_K** » Mon Jul 30, 2007 2:42 pm

wraithdu wrote:What should happen is the file should be renamed. What happens to me is that test.txt disappears from the real directory, and test2.txt appears in the sandbox. How bout the rest of you?

I added one step: I deleted the sandbox contents after creating C:\Download\test.txt on my "real" hard drive, and just before running a sandboxed cmd.

Result:
test.txt disappeared from the un-sandboxed C:\Download folder.
A "Download" folder and test2.txt showed up in the sandbox, after running the sandboxed cmd.

With the OpenFilePath=C:\Download\ I would have expected that the file would simply be renamed, not renamed and moved to the sandbox folder C:\Download.

SnDPhoenix · Post by **SnDPhoenix** » Mon Jul 30, 2007 3:14 pm

And, again i ask, why exactly do i not get these problems, and yes, i am doing it correctly......

wraithdu · Post by **wraithdu** » Mon Jul 30, 2007 3:45 pm

I have no idea. I tried this stuff at work also, on a completely different system than at home - different av, diff firewall, diff programs installed. I get the same problems. Ugh, my head hurts.

SnDPhoenix · Post by **SnDPhoenix** » Mon Jul 30, 2007 4:20 pm

Hmm, ok, ill try this on our computers at work and see if i get the problem, but thats not gonna be until 13-14 hours from now.

Sandboxie Support

Problem with OpenFilePath in 3.00.06

Who is online