Menu

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

New
nobody
None
High
Defect
2015-02-01
2014-03-20
Anonymous
No

Originally created by: yourbest...@gmail.com

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?

Discussion

  • Anonymous

    Anonymous - 2014-03-20

    Originally posted by: yourbest...@gmail.com

    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.

     
  • Anonymous

    Anonymous - 2014-03-20

    Originally posted by: yourbest...@gmail.com

    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?

     
  • Anonymous

    Anonymous - 2015-02-01

    Originally posted by: cflow...@gmail.com

    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.

     
  • Anonymous

    Anonymous - 2015-02-01

    Originally posted by: cflow...@gmail.com

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

     
  • Anonymous

    Anonymous - 2015-02-01

    Originally posted by: cflow...@gmail.com

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

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

     

Log in to post a comment.