bug: re-copying/resyncing already synced files....

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Setup the folder pairs from user documents sub-folder to dropbox user 
folder.  Password on each of the files in the folder
2. each pair, mirror original folder to encrypted folder is enabled, use 7z 
instead of cryptsync extension, set interval for full scans to 20 min
3. Every 20 minutes, all the files will copy themselves over and over again.  
In other words, the destination folder contents will be deleted and recopied.  

What is the expected output? What do you see instead?

The expected output is for the destination folder and/or contents will only 
change when the source folder changes.

Instead, on the next scan (every 20 minutes), the entire destination folder is 
deleted and then resynced/recopied again from stratch.  How does cryptsync know 
to delete these files?

What version of the product are you using? On what operating system?
1.1.5.257 64-bit, 2014.03.14 19:42:16;  Win7 SP1, 64 bit; logged in as 
administrator.

Please provide any additional information below.

I just realized that 1.1.5.257 is technically a beta, although the cryptsync 
website advertised 1.1.5 as the latest version.  If after a reboot the bug is 
not fixed, I will try 1.1.4. 64 bit.

I was wondering why dropbox syncing was so busy today as I installed cryptsync 
earlier today and started using it for the first time; dropbox syncing is 
normally very fast.

- is there a difference between 32 and 64 bit cryptsync?  Not sure if using 
32-bit would matter.
- btw, is cryptsync extension easily changeable to 7z extension?  In other 
words, is .cryptsync just a .7z file that uses a different extension name?

Original issue reported on code.google.com by yourbest...@gmail.com on 21 Mar 2014 at 12:07

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Here is  sample messge from the log:
03/21/14 07:10:36 : counterpart of file Serif\PagePlus\xxxxxxxxxxxxxxxx.abc 
does not exist in src folder, delete file.

But the file DOES exist in source folder.  Why isn't the program reading it/

I should add that one of the destination folders is inside of another 
destination folder.  This shouldn't create a conflict if each pair is treated 
separately, but I did figure it was worth mentioning.

And I should mention that when I right-click on the tray icon, and select "sync 
now" then the folders are not working properly

Before it was both pair destination folders.  But now it is only 1 pair that is 
deleting/resyncing everything.  I have no idea why.

Original comment by yourbest...@gmail.com on 21 Mar 2014 at 12:34

[GoogleCodeExporter]

I tried the older version and got the same error.

I then tried to use two separate folders as the destination folder for each 
pair 

\DropBox\subfolder\Pair1
\DropBox\subfolder\Pair2

This gives me zero re-writing bug :).

before I used 
\DropBox\Pair1
\DropBox\Pair1\[folder]\Pair2

The bug STILL EXISTS in being able to organize my folders how I want.  I may 
only want to sync specific folders at specific subfolders.  I shouldn't have to 
create a separate folder.  The sync algorithim should be smart enough to sync 
such that I can re-use destination folder and subfolders within a destination 
folder of a different pair.

I upgraded back to 1.1.5 .  The workaround of using separate folders for each 
destination pair AND making sure not to place a destination within a folder of 
an existing pair seems to work for now.  Thanks for giving us an easy method to 
encrypt our files for backup easily.

PS:  how does cryptsync store the password for each pair on the local computer 
cryptsync is installed on?

Original comment by yourbest...@gmail.com on 21 Mar 2014 at 4:27

[GoogleCodeExporter]

I think this could be used to solve the problem: 
https://github.com/secomba/base4k/tree/master/cs

Base4k was recently open sourced by the authors of Boxcryptor. It encodes 
filenames tersely by making use of unicode. As a result, it shortens filenames 
significantly, so that if you then encrypt them, you are still likely to be 
under the 260 char limit.

I don't have time to try it, but hopefully you will find it helpful.

Original comment by cflow...@gmail.com on 2 Feb 2015 at 4:22

[GoogleCodeExporter]

Oh, sorry -- I liked to the C# version of Base4K, but they have provided CPP 
and other languages as well.

Original comment by cflow...@gmail.com on 2 Feb 2015 at 4:23

[GoogleCodeExporter]

Sorry again! (It is late and my eyeballs are tired).

I meant to post this under the "filenames too long after being encrypted" issue.

Original comment by cflow...@gmail.com on 2 Feb 2015 at 4:24