Recycle bin about cppcryptfs HOT 22 CLOSED

It should be possible. I'm looking into adding that feature now.

from cppcryptfs.

Thanks!
Just FYI here is the Cryptomator registry hack.
No idea if it's relevant since it's not a network drive, but I've also noticed similar registry trees Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\Volume for volumes, so maybe it's possible to enable FUSE drive recycle bin by adding a custom GUID for it

from cppcryptfs.

Hi. I have the recycle bin working, but here is the situation.

If you run cppcryptfs not as administrator, then the recycle bin works only if plaintext filenames are used.

If you do run cppcryptfs as administrator, then the recycle bin works with both encrypted and plaintext flenames.

The problem appears to be that unless cppcryptfs is running as admistrator, windows does not let it create the gocrypfs.diriv files in the recycle bin directories. It is setting security attributes on these directories. I tried overriding them programatically when creating gocryptfs.dirv files, but I get access denied.

Is it workable for you if the recycle bin functionality requires that cppcryptfs be run as administrator if encrypted filenames are used?

I would make it put up a warning dialog that the recycle bin won't be available if you have the recycle bin enabled setting on and then mount an filesystem with encrypted filenames and aren't running as administrator (with a "stop showing this message" checkbox).

from cppcryptfs.

Yes, that would still be a huge improvement over the current situation without recycle bin. And during my initial evaluation I'm running cppcryptfs in admin mode anyway just to avoid any potential issues with those DACLs, and this seems to be that :)
Also, there seems to be an interesting bug in some file managers (e.g. Directory Opus), where cppcryptfs drive is recognized not only as a local NTFS drive, but also as a drive WITH recycle bin, so DOpus doesn't ask for a confirmation on delete (which is fine, but only for drives with recycle bins)

By the way, as an alternative without admin mode, wold it be possible to just move the decrypted folders/files (as is the case with Cryptomator at the moment)? It isn't ideal, but from my perspective still better than accidentally removing a folder with no way to restore it.

from cppcryptfs.

Actually, a quick google search made me realize that requiring admin rights is a non-issue, as there are trivial ways of making sure CppCryptFS is launched elevated without annoying UAC prompts (from this guide) by running a scheduled task.
You might want to add that to the description so that people, who want Recycle bin, but don't like the annoyance of UAC prompts can selectively disable them for CppCryptFS.

from cppcryptfs.

I've uploaded a binary on the releases page with a setting for enabling the recycle bin.

The recycle bin won't work without administrator privileges. cppcryptfs won't enable it unless it is run as admin.

from cppcryptfs.

Awesome, thanks a bunch!
However, now I have an issue with Dropbox telling me "Can't sync gocryptfs.diriv (access is denied)". Is this related and can it be fixed without disabling the recycle bin functionality?
Also, I started having cpprtyptfs crashes every time when I refresh the drive in Directory Opus after I delete a file, this is the error the debugger gave me

Unhandled exception at 0x00007FF682B4D290 in cppcryptfs.exe: 0xC0000005: Access violation reading location 0x0000019F0DADE000.

from cppcryptfs.

The gocryptfs.diriv file that dropbox cannot sync is the the one that's created in the recycle bin right after Windows creates the recycle bin on the encrypted volume.

I think dropbox normally ignores the recycle bin. But with encrypted file names, it has no idea that the recycle bin folder (a hidden system folder named $Recycle.Bin) is the recycle bin.

Windows lets cppcryptfs create the gocryptfs.diriv files in the recycle bin if cppcryptfs is run as administrator, but gocryptfs.diriv inherits really restrictive permissions that Windows uses on the recycle bin. So dropbox (which runs as the logged-in user) cannot access it (or probably anything else in the recycle bin).

If I go into Directory Opus and find that gocryptfs.diriv and grant myself full access to it, then dropbox syncs it.

I think one solution would be to not encrypt the name of the top-level recycle bin folder (e.g. "D:\$Recycle.Bin". Then I think dropbox would not try to sync it.

Do you think that would be an acceptable solution?

I am not having any luck reproducing the crash with Directory Opus that you described. Could you tell me the exact steps for how you delete the file and then refresh the drive? Also, is this filesystem being synced with dropbox at the time, or does it not matter?

from cppcryptfs.

Ok, thanks for the explanation. I think your suggestion is the right one - Dropbox should exclude the recycle bin from syncing (and if it doesn't then it's easier to exclude this folder manually if it's not encrypted - I've just excluded the Recycle bin folder (with encrypted folder name) from syncing in Dropbox and it's working just fine, no more "access denied" errors.

Re. the crash: all I have to do is just refresh after I delete a folder restored from Recycle bin (doesn't seem to happen when I delete a newly created folder), so the steps are as follows (no Dropbox process is running):
Update: sometimes it crashes when I simply delete a folder right after I've mounted, so it's not limited to folders restored from Recycle bin. Hard to spot a pattern, I've copied all my files to a new encrypted folder and it crashes, when I tried to replicate in a new empty encrypted folder, I couldn't do it

0. Open CppCryptFS in admin mode and mount an encrypted folder
1. Create a folder test with a text file test.txt
2. Delete this folder
3. Restore test folder from Recycle bin
4. Delete this folder
5. F5 Refresh
6. Observe a crash (every time)

from cppcryptfs.

Dropbox still attempts to sync the folder if it is name $RECYCLE.BIN. So not encrypting it doesn't solve the problem by itself. I guess Dropbox never normally encounters a recycle bin because you don't normally (and probably can't) sync the root directory of a volume.

Even though not encrypting that name would make it easier to find the recycle bin and exclude it, I think it's not a good idea because it would break compatibility with gocryptfs.

I plan to enhance the -l, --list command line option to show the encrypted and decrypted names side by side. I think this is a better way to assist in finding the recycle bin for the purpose of excluding it.

I also found that if I run Dropbox as administrator, then Dropbox can sync the recycle bin (and the gocryptfs.diriv files inside it).

I still have not been able to reproduce the crash with Directory Opus.

Do you think you could try generating a memory dump for me?

I found this tool called procdump that will generate a memory dump when an app crashes.

https://docs.microsoft.com/en-us/sysinternals/downloads/procdump

I added a line of code to a test version of cppcryptfs that intentionally crashes it, and I was able to find the line of code using the memory dump generated by procdump.

if you create a directory c:\dumps and then run (in an administrator command prompt)

procdump64 -ma -i c:\dumps

Then when cppcryptfs crashes, you should see a file in c:\dumps like

cppcryptfs.exe_170919_111749.dmp

If there is more than one, I should need only the last (highest numbered) one.

It will be a huge file (100MB or so). 7zip should be able to compress it to about 26 megabytes.

The biggest attachment github allows is 10MB. You could use 7zip to split it into 10MB pieces (e.g. cppcryptfs.exe_170919_111749.dmp.7z.001, 002, etc). and then rename them to .zip (e.g. cppcryptfs.exe_170919_111749.dmp.001.zip, etc) so github will allow you to upload them.

I cannot say with 100% certainty, but I think if you create a new encrypted filesystem, use some password you would never use normally, and put only non-sensitive data there (e.g. the cppcryptfs source code), and then reproduce the problem, then I think the memory dump probably won't contain any personal or sensitive information.

I am attaching two cppcryptfs exes in a zip file. One is a release build and one is a debug one. If you can reproduce it with the debug build, then that would be better. I needed to make a new build because I didn't save the exact program database files I used when I did the last release. I've saved the pdb files that go with these executables.

cppcryptfs_debug_dir_opus.zip

The sha256 of the zip file is 1007c1f4640e78e2d3d4398e478d61414acf793de2a616c7bc2f4a1685473f36

from cppcryptfs.

I'd agree that breaking compatibility for a minor extra convenience (of a familiar folder name) might not be a good idea, but adding information about the folder name would be valuable. I'd imagine two ways to make it visible to the user:

• in the GUI next to the option of turning on the Recycle bin
• in the list of drives/paths

I'll do some testing later with your stable/debug builds and try to generate a crash dump that would allow you to pinpoint the issue (will likely just encrypt the file and email you the password to avoid having dumps in the open)

from cppcryptfs.

I've made the --list option have an optional argument which should be the full (unencrypted) path to a file or directory. If you run

start /wait cppcryptfs.exe --list=k:\

Then it should show you something like

$RECYCLE.BIN => Q9-T45wKtN7cfua4gbkM2A
foo => i3ULkArrZEeqtgCNQGMN3w
foo.txt => 4uKLgOSia1H5UKZ6CxwXXQ

If you're running cppcrypts as administrator, then you'll need to run it with the --list command from an administrator cmd.exe window as well. I didn't realize that the new (command line) instance can't talk to the already-running instance if the already running is administrator and the new instance isn't also running as administrator. I made the new version print out a message to this effect if it detects that this probably happened.

from cppcryptfs.

I have github set up with my spam email account. Please let me know when you have the dumps ready.

I'll make my profile display my email address then and reply back to the ticket, and then when I've go the dumps, I'll try to make it undisplay it. I get so much garbage in that email I wonder whey I should bother, but anyway, I'd like to do it that way.

It's a gmail address. I read that I can receive files up to 50MB, so I think you could just email me the dumps.

from cppcryptfs.

I've emailed you the crash dumps with a subject CppCryptFS crash dump (issue #19)
Alternatively, feel free to change your email address at your github profile if it's easier for you than finding my email in your spam account, I'll just forward that email to the new account. By the way, the limit on attachments is 25MB, not 50 :(

Just FYI this crash occurred in Windows Explorer (not Directory Opus, I tried to make it simpler and see if I can get an error in the standard Windows environment).
The steps to cause this crash were simply a bunch of copy/delete/undelete/delete/copy etc. operations

1. Create a folder aSource with cppcryptfs-1.3.0.3 and cppcryptfs-1.3.0.5 and their respective exe files (so it's 4 files, two zip files and two exe files + two folders with zip files unpacked), downloaded from GitHub
2. Make two copies of this folder
3. Copy these 3 folders to a new CppCryptFS drive
4. Delete these 3 folders
5. Undo delete
6. Delete again
7. Copy the same 3 folders again
8. Delete these newly copied 3 folders
9. Crash

from cppcryptfs.

I tried your steps to reproduce the crash, but I can't make it crash.

I loaded your memory dump in the debugger and got a reasonable stack trace.

It looks like it crashed in the code that caches the mappings from the all uppercase filenames to the filenames in the correct case. The cache is there to speed up the case-insensitive mode.

To save memory, I was keeping a pointer to the uppercased path in one place where I needed it instead of a copy of that string. It looks like the string got deleted, when I went to delete that cache entry to make room for a new one, I had a dangling pointer, which is what caused the crash. I looked over the code, and can't find the bug that causes the pointer to be dangling.

As a quick and dirty fix, I changed the code to use a copy of the string there instead of the pointer to it.

I also noticed that I was making non-standard use of the

stl::list I used for keeping track of LRU (least-recently-used) in the cache. I changed it to do what it was doing the standard way.

The diriv cache works very similarly. I changed it as well.

Here is a zip file with the new executables. Please see if you can still reproduce the crash with the debug version, and if not then try the release version. If it still crashes, I'd prefer a memory dump from the debug version if possible.

cppcryptfs_attempted_fix.zip

The sha256 of the zip file is 2e183341a2c39749ae3199caf97a36c61b8ff41d4a49a7fd35a5d6d04e264ec7

from cppcryptfs.

You might want to try to do the operations a few times, it's doesn't happen 100% of the time. Might also want to change the order of the operations ;) I'm not sure what exactly causes it, so as I mentioned above, I just did some "bunch of copy/delete/undelete/delete/copy etc. operations"

I've still got a crash with the new version and the same steps, will try to reproduce it with a debug running and send you another memory dump

from cppcryptfs.

Emailed you the dump, steps to reproduce are almost identical, though this time I needed to repeat the copy&delete&undelete cycle twice as it didn't crash the first time during my tests with procdump on (though it did crash on the first cycle the first time I tried the same set of steps)

from cppcryptfs.

Thanks for the memory dump.

I tried what you said and did a bunch of copy/delete/undelete operations and can make it crash myself now.

Every time it crashes (both in your memory dumps and when I reproduce it), it is crashing in the case cache code.

I think my case cache must be broken. In my latest crash, I see inconsistencies in the data structures that should never happen.

I'll keep staring at the code for a while. If I can't figure out what's going wrong, then I'll try re-writing it.

from cppcryptfs.

I think I found the problem. I fixed a couple of bugs in the case cache, and now I can't make it crash.

Please try this build.

cppcryptfs_attempted_fix2.zip

The sha256 of the zip file is 4d67afdb61d8ca9f68128bbbf41e647a309b6a5761a81a127f398c03389c5ff5

from cppcryptfs.

Thanks for the fix, doesn't crash for me either during the test steps above. Will keep an eye for it while using it in the future, trying to do a bit more of delete/restore etc. operations to see how well it fares.
By the way, during my tests I've got another error:

0x80070091: This directory is not empty

The folder appears as empty in my file manager.
Maybe it's due to the fact that I'm trying to delete a folder with the same name then restore it and then delete it again and it doesn't understand, which one to restore or something (just a guess). When I unmount and mount the folder again, this problem is fixed, the folder both appears as NOT empty and can be removed

from cppcryptfs.

Thanks for the feedback. I just now made a new release 1.4.0.1 with that fix for the crash in it. I hope it stays fixed :-)

from cppcryptfs.

Updated and also hope it stays fixed :)

from cppcryptfs.