Open GoogleCodeExporter opened 9 years ago
CryptSync relies on the file date (last write time) to determine whether it
needs to encrypt/decrypt a file. If the file date hasn't changed, it does
nothing.
Original comment by tortoisesvn
on 2 Feb 2013 at 1:12
Good to know the basics that it relies on the filedate.
But I have to clarify this I think.
The problem was, that the INITIAL decryption of all encrypted files into a
completely empty new folder stopped after some files.
So the situation was like this:
Folder A (Googledrive) contains encrypted files.
Folder B was now created as new folder on my drive
CryptSync: added new folder pair, and let it start "syncing" / decrypting my
files into the new folder. This startet and sucessfully decrypted some files
but was never finished the remaining files and no errormessage was shown.
Original comment by FritzBox...@gmail.com
on 2 Feb 2013 at 7:30
Tried to decrypt a folder with 3526 files in it (filenames encrypted as well).
Did it three times, all worked just fine.
So it seems I can not reproduce this.
I leave the issue open - if you ever find out how to narrow down the source of
the problem please add a comment here.
Original comment by tortoisesvn
on 3 Feb 2013 at 3:40
As for your initial suggestions:
1) that's a good idea. I'll implement something like this.
2) "force sync now" is already done: start CryptSync, doubleclick on the tray
icon to bring up the dialog, then click on "sync and exit".
3) Not sure how that would be an improvement, but I'll keep it in mind.
4) a virtual drive requires a file system driver. Since those run in kernel
space, not user space, a bug in there will cause a BSOD, not just an app crash.
That's why I won't go that way. I like to keep things simple and safe.
Original comment by tortoisesvn
on 3 Feb 2013 at 3:44
3) (Inventory) Not sure how that would be an improvement, but I'll keep it in
mind.
Once I needed only some special files and don't wanted to sync all 5GB to
access them.
Think about mobile devices, the advantage is that you use a common used program
7zip for it and so you are always able to decrypt your files if you know the
password and don't need a special program that may not be ported to for example
andorid.
So if you need a single folder / file you don't need to sync all files to your
mobile device to be able to find it and use it.
I call this an "improvement" :)
4) a virtual drive requires a file system driver. Since those run in kernel
space, not user space, a bug in there will cause a BSOD, not just an app crash.
That's why I won't go that way. I like to keep things simple and safe.
I fully understand your point here and agree that the kernel space is a bit out
of scope.
But it should be possible to do all this in userspace as "Shell Namespace
Extension".
Some usefull links:
"Flicker Drive" as Shell Namespace Extension with full source code
http://www.viksoe.dk/code/flickrdrive.htm
as mentioned here:
http://stackoverflow.com/questions/8438066/writing-namespace-extensions-with-win
dows-7-integration
Maybe once you don't know what to do else, you want to play with it :)
Original comment by FritzBox...@gmail.com
on 10 Feb 2013 at 4:13
Most applications don't work with virtual files, so the shell namespace
extension would be mostly useless.
Original comment by tortoisesvn
on 2 Apr 2013 at 7:42
Original issue reported on code.google.com by
FritzBox...@gmail.com
on 26 Jan 2013 at 8:03