![]() |
| SB asks for quick recovery even if not required! |
|
tzuk
|
If you're going to set a Quick Recovery folder as an entire drive, as in the case of D:\, then what you describe is to be expected.
If you want fewer Immediate Recovery notifications, be more discrete with your choice of Quick Recovery folders. |
||||||||||||
|
_________________ tzuk |
|||||||||||||
|
exus69
|
Hi Tzuk, I dont have any issues with Immediate recovery window popping up as many times as I open a document, make some changes to it and save it. The problem occurs when Sandboxie tries to auto-delete the Sandbox and pops up a window to quick recover some files in it even if they have already been immediately recovered previously or if I've just opened the document to read it and then closed it without any changes. For eg. I created two word files in 2 different folders in D:\ so its file size is 0 bytes coz its empty. Now if I close that file without editing at all I get the following window to quick recover them. http://i1119.photobucket.com/albums/k631/exus69/SB.jpg Quick recovery should pop up if I do some editing in those documents and dont immediately recover them or if I manually invoke Quick recovery right? Then how come am getting a Window for quick recovery even if I havent done any editing in the files?? Please help |
||||||||||||||
|
|
|||||||||||||||
|
tzuk
|
Then if I understand correctly, you're saying that zero-length files should not appear in the Quick Recovery window, in the same way that zero-length files don't appear in Immediate Recovery pop-ups. Yeah?
|
||||||||||||
|
|
|||||||||||||
|
exus69
|
Hi Tzuk, thx for your prompt reply. Yes thats right but its not only a question of zero length files
appearing in Quick recovery window. Ok let's take the same previous example forward. Suppose in one of those 0 byte doc files I make some changes and close it, SB will prompt for Immediate Recovery because I've added D:\ in my Quick recovery box. After I Immediately recover the file, the Sandbox does NOT auto-delete (I've set the Sandbox to auto-delete). Also I made sure no other program is Sandboxed at the time the file is Immediately recovered. In other words, I noticed that auto-delete function is not working after I select either Recover or Close in Immediate Recovery box(Although it is working sometimes, it is supposed to work everytime since it says auto-delete on exit of Sandboxed programs) -------------------------------------------------------------------------------------------------------------------- Coming back to the 0 byte doc file, lets say I edit and add some info, save it and close the file(now lets say the file is 10 bytes), the Immediate Recovery window will pop up. I select recover and the file is recovered from the Sandbox onto the real system. Let's assume that the Sandbox auto delete works properly this time. After 2 hours suppose if I open the same file to read not edit and then when I close the file SB prompts me to Quick recover the same 10 bytes file which I had opened to read alongwith an option to delete SB contents due to auto-delete feature!! The quick recovery feature is supposed to run if I forget to Immediate recover files right? In this case what happens is, the user will get confused. He'll think that he has already Immediately recovered the 10bytes doc file then why is SB again asking to quick recover the same 10bytes doc file. I hope am not confusing you. Am trying to be as verbose as possible. Please help |
||||||||||||
|
|
|||||||||||||
|
Guest10
|
I wonder if a part of the behaviour that exus69 is seeing, is due to using Word in the examples.
I have an older version of Word, so I don't know if this applies to later versions. When I use a sandboxed Word to open a file, the file is opened for Editing (update) and not for Reading (view). The file is copied into the sandbox, and a temporary file based on the same name is also created in the sandbox: "~$xxxxxx.xxx" If I do not edit the file at all, the temporary file is deleted when I close the document, but the copy of the original file remains in the sandbox. Running Quick Recovery, or Delete Contents after Word is exited, will result in a prompt to recover the file. This behaviour is not the same if Notepad is used instead of Word. Sandboxed Notepad does not copy the original file into the sandbox when it is opened. Only an edit to the original file will result in the file being saved in the sandbox, and then it will show up in a Quick Recovery prompt. |
||||||||||||
|
_________________ Paul XP Pro SP3 (Admin rights), Zone Alarm Pro Firewall, Malwarebytes Pro, Firefox 21, Thunderbird 17 |
|||||||||||||
|
tzuk
|
I'm afraid you are confusing me a bit. But I think perhaps Guest10's point answers your question. If the program you use is causing Sandboxie to make copies of files in the sandbox, then Quick Recovery is going to show you that the sandbox contains some files. But to address the problem, perhaps I should revise Quick Recovery so that it doesn't show: - files with zero length (as I said before) - files in the sandbox which are exact duplicates of files outside the sandbox |
||||||||||||||
|
|
|||||||||||||||
|
exus69
|
This is what shouldn't happen. If no edit to a Sandboxed Word document(or to any other type of file for that matter for eg.xls) also results in Quick Recovery popping up then it will lead to user inconvenience. Sandboxie is an OUTSTANDING program and tight security has always been in an inverse relation with user convenience. Techies dont mind recovering files from SB but a prompt for every opened file even if not edited will be a bit of a hassle to a normal computer user.
Tzuk, the second point will solve the above issue.
Tzuk, what do you think about this problem? |
||||||||||||||||||
|
|
|||||||||||||||||||
|
tzuk
|
I'm not sure what to say about the auto-delete problem. Perhaps something in your computer is occasionally preventing auto-delete, but I don't think it has to do with recovery prompts.
|
||||||||||||
|
|
|||||||||||||
|
exus69
|
Ok Tzuk will try it out again
Tzuk, when will you release the above fixes?? |
||||||||||||||||
|
|
|||||||||||||||||
|
tzuk
|
I will post an update in this topic when I release a version that implements these changes.
|
||||||||||||
|
|
|||||||||||||
| Done |
|
exus69
|
Thanks alot Tzuk
|
||||||||||||
|
|
|||||||||||||
|
Buster
|
"files in the sandbox which are exact duplicates of files outside the sandbox" What hash are you going to calculate to see if files are duplicates? For big files, hashing can be time consuming, specially in old PCs. |
||||||||||||||
|
|
|||||||||||||||
|
tzuk
|
To hash a file you have to scan its full contents and calculate some number. But if I have to scan through both files anyway (and I do) why bother with numbers when I can compare the contents byte for byte, and not deal with the (very small, but nonzero) chance of a hash collision. As for large files, of course they would have to be excluded from such processing.
|
||||||||||||
|
|
|||||||||||||
| Thank You |
|
exus69
|
Thanks alot Guest10, Buster and Tzuk
Appreciate your efforts. |
||||||||||||
|
|
|||||||||||||
| SB asks for quick recovery even if not required! |
|
||
|


Use the RSS feed to watch this topic for replies