Bug report 1.1.15: Change & move of big file results in old, non-synced file on sync target

[hhz]

Hi,

here's something odd.

I have converted my CD collection to FLAC and right now I'm trying to clean up the tags and cover images. For that, I'm using different computers, thus the need for btsync.

The workflow is like this: I modify the tags and store an album image into the FLACs of an album's folder (this operation will update the file's timestamp), then move the whole folder from "/Audio/Unsorted" to "/Audio/Sorted".

On the target system, btsync will then move the _old_ versions of the file to the new location and not update the file's content.

Using btsync 1.1.15.

Thanks!

[hhz]

Ok, tried again. The tagging software (easytag on Linux) did not update the timestamp, but kept the old one. So that explains it.

[rdebath]

It's still a bug. The files in the new location have the wrong checksum and if the metadata gets regenerated for some reason it'll probably be rather random which version of the file ends up as the 'official' version.

[hhz]

Well, if you ask me, that timestamp-based method is a very bad choice. It will most likely become the main reason for sync headaches with btsync.

[rdebath]

Well, yes.

Nobody wants the modified time method it's just that it's easy. Even deletes are easy if you leave a zombie in your metadata file.

From what I understand the 'rename the oldest copy' is the one that gives the best results in normal mirror application.