Not all files decrypted, no error shown, some ideas

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Not completely sure how to reproduce, if I find out, I will let you know. I 
thin kI can repdroduse with my file + key kombination, but of course I don't 
want this to be shared.

2. Setting was: Encrypt Files and Filenames , Googledrive, many files

What is the expected output? What do you see instead?
Automatic decryption of all files or if not then error message

What version of the product are you using? On what operating system?
cryptsync 1.05.168, Windows 8 x64 Pro, Googldedrive 1.7.4018.3496

Please provide any additional information below.

My problem short:
The prgoram did not unencrypt all encrypted files back but didnot show any 
error.

I think it was caused by a folder with 67 chars, encrypted it gets a looong 
string with 135 chars. I tryed to exit CryptSync and run again, did syn and 
exit, did run in background, nothing helped, it always shoed it would be all ok 
but it did not unencrypt everything. After I deleted this one long encrypted 
file and folder (html webpage + its folder) it was working again.

Another problem was, if I copy encrypted files in the encrypted folder, the 
files get not decrypted into the other folder.

So I had some ideas:

1. cryptsyn should get a button / cmd param named "Diagnose":

clicking it would:
- scan both configured directories, how many files each one has and log the 
differences if
- create two testfiles  (should not overwrite a possible existing file), one in 
the unencrypted one and let it encrypt to the other folder, check result, then 
create a testfile in unenrcypted folder and let it unencrypt
- check ntfs / needed permissions and do other checks ...

2. a button "force sync now" to un-/encrypt files in each folder now

3. you could keep some kind of "inventory" of all files (encrypted) and write 
some kind of file/folderbrowser ontop of this file, so one can browse his 
encrypted files and maybe extract selected files7folders to somewhere

4. and if you want to improve even further, you could implement the handling 
like "cloudfogger" (seems to be the same people behind teamviewer ), create a 
virtual drive as layer between showing all unencrypted filenames without the 
need to sync all files again and bind your special file extension so you can 
decrypt on the fly and open the right application like word for docx-files 
afterwards.

Original issue reported on code.google.com by FritzBox...@gmail.com on 26 Jan 2013 at 8:03

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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