It seems the program is deleting large amounts of data files in bulk
automatically when it is undesirable to do so and should not be doing so. I am
running the sync program in batch mode with "ignore errors" parameter set,
triggered by RealTimeSync. Consider the following scenario:
Computers A, B, and C. Folder pairs are synced across each and every computer.
Computer A is off. RealTimeSync triggers FreeFileSync to run on Computer B.
Computer B begins comparison with Computer A. Computer A is off and results in
the sync program to mark the folders on Computer A as empty. Computer B
continues comparison with Computer C then begins synchronization after
comparison. The sync program attempts to locate the folders on Computer A
again and renders "error path not found", then continues to sync with folders
on Computer C. At this point, each and every folder pair should be "locked" by
the sync program on both Computers B and C by way of the lock file.
Computer A is turned on. RealTimeSync on Computer A triggers its own sync
program and begins synchronization with Computer B. It appears that Computer A
was able to engage in comparison with Computer B while Computer B was syncing
with Computer C. Computer A then goes on to issuing a "deletion lock" on
folders on Computer B and begins deleting entire folders and sub-folders on
Computer A.
For me, this is hugely undesirable and causing me problems. Because gigs of
data have been deleted and I am constrained by low bandwidth, to recopy the
data onto Computer A by syncing would take more than a month. Perhaps, there
is some better alternative to address the above scenario to make the program
more efficient. I believe the above results because of the way the program
handles unfound network paths during comparison.
At least, in manual syncing, I can instruct the program to either "retry" or
"abort" when the paths are not found. However, when in batch mode, there is no
retry and the option to "exit on errors" will cause the entire sync to abort
prematurely.
Possible Undesired Deletions
- Posts: 5
- Joined: 15 Sep 2011
- Posts: 5
- Joined: 15 Sep 2011
Or maybe, the deletion on Computer A occurred because it was not able to
compare with Computer B as a result of Computer B's folder lock. Otherwise, I
assume it would have found that files existed on Computer B and would not
propagate a delete on Computer A. But for some reason, I caught the sync
program in action issuing a "delete lock" on folders on Computer B and then
deleting entire folders on Computer A.
compare with Computer B as a result of Computer B's folder lock. Otherwise, I
assume it would have found that files existed on Computer B and would not
propagate a delete on Computer A. But for some reason, I caught the sync
program in action issuing a "delete lock" on folders on Computer B and then
deleting entire folders on Computer A.
-
- Site Admin
- Posts: 7050
- Joined: 9 Dec 2007
This is going to be difficult, but let's see if we can figure this out:
> Computer A is turned on. RealTimeSync on Computer A triggers its own
> sync program and begins synchronization with
> Computer B. It appears that Computer A was able to engage in
> comparison with Computer B while Computer B was syncing with Computer C.
This should not be possible, since this is what the sync.ffs_lock is for. I
don't think this is the problem here, but if you find a way to reproduce the
lock file not begin honored, please provide me more information to nail the
issue down.
> "deletion lock"
This is just another lock, to guard the task of deleting the lock file. This
doesn't have anything to do with deleting any of your production files.
> maybe, the deletion on Computer A occurred because it
> was not able to compare with Computer B as a result of Computer B's folder
lock.
No, folder locking causes the application to wait, no matter how long it
takes. This is *never* interpreted as "not existing".
Here's my theory on what I think has happened:
First one has to know that FFS has two important features to prevent excactly
the situation of deleting a target directory if source is (temporarily) not
available. First, if the source becomes unavailable *while* FFS is scanning it
or FFS misses access rights to access certain folders, these folders in
question are excluded from synchronization (= temporary unchecked) for *both*
sides.
The second feature is more "blunt": If FFS detects that a synchronization
consists of deletions only, just before starting synchronization it checks
once again if source folder (:= the other side) is existing. If not, it
cancels the synchronization with a fatal error, due to not existing source
folder. If yes, then the source folder is interpreted as just empty, we are
not in an error situation and FFS propagates all deletions.
Theory:
When A was powered on and FFS started comparison, the connection to B was not
yet established. FFS ignored the error and set all files on A to deletion.
Meanwhile, just before FFS is about to start synchronization, B becomes
available. The second check mentioned above found "source directory existing",
and did not abort synchronization, although it should.
This is clearly a TODO for FFS, even if it turns out, the problem is something
completely different.
The only thing I don't understand is:
> Computer A then goes on to issuing a "deletion lock"
Deletion lock is only created if FFS finds an "abandoned" lock file. A lock
file can become abandoned, if the lock owner, namely some FFS instance is no
longer available, crashes or if the connection is interrupted unexpectedly,
e.g. power loss, network failure, or just the user pulling the plug, no matter
what the reason. The new FFS instance that wants to gain the lock checks if
the exising lock file is active by monitoring it for about half a minute. If
it notices no activity (= change in file size) it is considered abandoned, and
it issues the "deletion lock", solely for the purpose of gaining unique right
to clean up the abandoned lock. The algorithm is recursive, so the same
argumentation concerning abandoned locks, applies equally to abandoned
deletion locks.
What's puzzling is that in your descriptions, you did not mention unexpected
interruptions for any FFS instance. Consequently an abandoned lock should not
occur.
However let's make clear that there are two unrelated problems to be
discussed: 1. total deletion oon A 2. existence of an abandoned lock
Even if the lock file feature were not available at all, 1. should not happen!
> Computer A is turned on. RealTimeSync on Computer A triggers its own
> sync program and begins synchronization with
> Computer B. It appears that Computer A was able to engage in
> comparison with Computer B while Computer B was syncing with Computer C.
This should not be possible, since this is what the sync.ffs_lock is for. I
don't think this is the problem here, but if you find a way to reproduce the
lock file not begin honored, please provide me more information to nail the
issue down.
> "deletion lock"
This is just another lock, to guard the task of deleting the lock file. This
doesn't have anything to do with deleting any of your production files.
> maybe, the deletion on Computer A occurred because it
> was not able to compare with Computer B as a result of Computer B's folder
lock.
No, folder locking causes the application to wait, no matter how long it
takes. This is *never* interpreted as "not existing".
Here's my theory on what I think has happened:
First one has to know that FFS has two important features to prevent excactly
the situation of deleting a target directory if source is (temporarily) not
available. First, if the source becomes unavailable *while* FFS is scanning it
or FFS misses access rights to access certain folders, these folders in
question are excluded from synchronization (= temporary unchecked) for *both*
sides.
The second feature is more "blunt": If FFS detects that a synchronization
consists of deletions only, just before starting synchronization it checks
once again if source folder (:= the other side) is existing. If not, it
cancels the synchronization with a fatal error, due to not existing source
folder. If yes, then the source folder is interpreted as just empty, we are
not in an error situation and FFS propagates all deletions.
Theory:
When A was powered on and FFS started comparison, the connection to B was not
yet established. FFS ignored the error and set all files on A to deletion.
Meanwhile, just before FFS is about to start synchronization, B becomes
available. The second check mentioned above found "source directory existing",
and did not abort synchronization, although it should.
This is clearly a TODO for FFS, even if it turns out, the problem is something
completely different.
The only thing I don't understand is:
> Computer A then goes on to issuing a "deletion lock"
Deletion lock is only created if FFS finds an "abandoned" lock file. A lock
file can become abandoned, if the lock owner, namely some FFS instance is no
longer available, crashes or if the connection is interrupted unexpectedly,
e.g. power loss, network failure, or just the user pulling the plug, no matter
what the reason. The new FFS instance that wants to gain the lock checks if
the exising lock file is active by monitoring it for about half a minute. If
it notices no activity (= change in file size) it is considered abandoned, and
it issues the "deletion lock", solely for the purpose of gaining unique right
to clean up the abandoned lock. The algorithm is recursive, so the same
argumentation concerning abandoned locks, applies equally to abandoned
deletion locks.
What's puzzling is that in your descriptions, you did not mention unexpected
interruptions for any FFS instance. Consequently an abandoned lock should not
occur.
However let's make clear that there are two unrelated problems to be
discussed: 1. total deletion oon A 2. existence of an abandoned lock
Even if the lock file feature were not available at all, 1. should not happen!
- Posts: 5
- Joined: 15 Sep 2011
Thank you for the informative post. With regard to the question of "deletion
lock", I may have an explanation for this. Computer B was definitely still
running FFS and syncing with Computer C. However, the bandwidth goes anywhere
from 80 Kbits to 600Kbits per second. So if the transfer was at 80 Kbits for
30 seconds, maybe the amount transferred was too small for FFS to detect and
concluded an abandoned lock incorrectly. Otherwise, I have no other
explanation for this because FFS was definitely active and running on Computer
B.
As to the issue of the total deletions on Computer A, based on the certain
failsafe features you mentioned, I would agree that the deletions should not
have happened on A. Even though you assure that when the folders on Computer A
are unavailable, the folders on Computer A are excluded from synchronization,
the FFS running on Computer B returns the message during comparison that the
folders on Computer A will be "considered empty" when "Ignore on error" is
chosen. The language of this message causes me to worry and as a result of
this incident. I now run FFS manually and always either chose Retry or Abort
when a network folder becomes unavailable, afraid to hit Ignore. If there is
no cause for worry, then maybe the message should be revised such that "this
folder pair will not be synchronized for this session" when "Ignore" is
chosen. However, I do not have any further information to contribute as to why
it propagated whole deletion on Computer A.
lock", I may have an explanation for this. Computer B was definitely still
running FFS and syncing with Computer C. However, the bandwidth goes anywhere
from 80 Kbits to 600Kbits per second. So if the transfer was at 80 Kbits for
30 seconds, maybe the amount transferred was too small for FFS to detect and
concluded an abandoned lock incorrectly. Otherwise, I have no other
explanation for this because FFS was definitely active and running on Computer
B.
As to the issue of the total deletions on Computer A, based on the certain
failsafe features you mentioned, I would agree that the deletions should not
have happened on A. Even though you assure that when the folders on Computer A
are unavailable, the folders on Computer A are excluded from synchronization,
the FFS running on Computer B returns the message during comparison that the
folders on Computer A will be "considered empty" when "Ignore on error" is
chosen. The language of this message causes me to worry and as a result of
this incident. I now run FFS manually and always either chose Retry or Abort
when a network folder becomes unavailable, afraid to hit Ignore. If there is
no cause for worry, then maybe the message should be revised such that "this
folder pair will not be synchronized for this session" when "Ignore" is
chosen. However, I do not have any further information to contribute as to why
it propagated whole deletion on Computer A.
-
- Site Admin
- Posts: 7050
- Joined: 9 Dec 2007
> maybe the amount transferred was too small for FFS to detect and concluded
an abandoned lock incorrectly.
FFS doesn't monitor bandwitdh, but the file size of the lock file. Every 5
seconds it is incremented by one byte. It should always be possible to update
one byte within a time frame of 35 seconds, except the connection is really
cut.
>assure that when the folders on Computer A are unavailable, the folders on
Computer A are excluded from synchronization
Treating a non-existent directory as empty and excluding directories that do
not exist anymore, *after* the first check has shown that they exist at that
time, are really two completely different checks serving different purposes.
The first one handles the case that a target directory is not yet existing and
should be created during synchronization. The second one protects against
unexpected network drops.
The design flaw in the old FFS version was, that folder existence was
redundantly checked a *second* time during synchronization instead of using
the status from time of comparsion.
Nevertheless this problem is solved in the new version: FFS now checks folder
existence just *once* during comparison; if during file traversing, all or
some of the folder content is unaccessible, the relevant part is excluded from
synchronization. If a folder does not exist up front and user chose to ignore
this error *and* this would have all files deleted, this results in a fatal
error, skipping this folder pair during synchronization. If it conversely
would create files on a non-existent target directory, this operation is
permitted, though. This is a clean and comprehensive solution. Here is the
updated version, if you want to do some tests:
[404, Invalid URL: http://ifile.it/jt1xmsd/FFS] v3.22 beta8.rar
Best regards, Zenju
an abandoned lock incorrectly.
FFS doesn't monitor bandwitdh, but the file size of the lock file. Every 5
seconds it is incremented by one byte. It should always be possible to update
one byte within a time frame of 35 seconds, except the connection is really
cut.
>assure that when the folders on Computer A are unavailable, the folders on
Computer A are excluded from synchronization
Treating a non-existent directory as empty and excluding directories that do
not exist anymore, *after* the first check has shown that they exist at that
time, are really two completely different checks serving different purposes.
The first one handles the case that a target directory is not yet existing and
should be created during synchronization. The second one protects against
unexpected network drops.
The design flaw in the old FFS version was, that folder existence was
redundantly checked a *second* time during synchronization instead of using
the status from time of comparsion.
Nevertheless this problem is solved in the new version: FFS now checks folder
existence just *once* during comparison; if during file traversing, all or
some of the folder content is unaccessible, the relevant part is excluded from
synchronization. If a folder does not exist up front and user chose to ignore
this error *and* this would have all files deleted, this results in a fatal
error, skipping this folder pair during synchronization. If it conversely
would create files on a non-existent target directory, this operation is
permitted, though. This is a clean and comprehensive solution. Here is the
updated version, if you want to do some tests:
[404, Invalid URL: http://ifile.it/jt1xmsd/FFS] v3.22 beta8.rar
Best regards, Zenju
