Sync.ffs_lock File

[aiadi]

Why is the new version of FFS leaving this file within the synchronised
directories? Is this by design or is it some sort of a bug?

[Zenju]

These lock files serialize access to a directory in case multiple processes of
FFS (on the same or different PCs) want to modify it. The lockfile is deleted
when an instance of FFS that currently owns a lock does not need it anymore,
program exit at the latest.

[aiadi]

Thanks, Zenju, but one of the files is stuck in one of my folder pairs even
after the program exits.........

[Zenju]

Did the program crash or not end properly? Can it be reproduced?

[aiadi]

Sorry for the late reply but I was busy with work. No the program did not
crash or end unexpectedly. The error is actually 100% reproducible and I think
it is a bug related to having multiple folder pairs with more than one pair
sharing the same source folder (i.e like a folder triangle). the file gets
deleted from two of the folders after the sync is done but stays stuck in the
third one. I hope this makes sense (and more importantly I hope it is
fixable). Let me know if I could offer you more information to help.

[Zenju]

>Let me know if I could offer you more information to help.
Yes, I tried to reproduce it, but did not succeed. Do you have some detailed
steps I need to take?

[zardoz35]

I have the file sync.ffs_lock created when I want to sync a list of folders
(more than 100) of my pc to a directory of my usb key everytime

I reproduced every time

There is a countdown then freefilesync sync the data. No crash.

(je peux expliquer plus précisément mais en français)

[zardoz35]

the content of the file in hexa :
50 4B 42 41 43 4B 23 20 30 30 31 08 00 00 00 00 00 00 00 00 00 00 9D 73 23 3B
00 00 00 00 00 00 42 20 00 69

[Zenju]

The existence of this locking file is by design. As long as the file is
properly deleted on program shutdown or when other directory pairs are
compared, we don't have a problem.

[zardoz35]

the file is deleted at program shutdown, I just verified it
But, if I don't close the program, eject the usb key and insert my second key,
the file is NOT deleted

[Zenju]

True, this is indeed undesired behavior. On the other hand I want this locking
mechanism to be as unintrusive as possible, without an explicit user option.
From a logical point of view locking needs to start before comparison and stop
after synchronization. It's not easy to harmonize this with all real-word
situations. Maybe we need a compromise here (unless there is a solution that
covers even these cases)

[zardoz35]

a solution : when I click on synchronisation complete, you can delete this
file ?

[Zenju]

At this point the directories are still susceptible to write access: 1. If
sync didn't finish completely, user may try again with the remaining items 2.
User manually deletes files, then syncs

[aiadi]

"At this point the directories are still susceptible to write access: 1. If
sync didn't finish completely, user may try again with the remaining items."
But that seems what is causing my problem. As the files is not deleted a re-
run of FFS (without completely closing FFS) is causing the dreaded file to
come up as a conflict (only present in one side). Sync this one and it is
stuck into the target folder forever (even when I exit FFS).

[Zenju]

> is causing the dreaded file to come up as a conflict
The lockfile should not have any impact on synchronization as it is already
excluded during comparison.

Do you have some detailed descriptions about what goes wrong and how you
reproduce it?

[aiadi]

"as it is already excluded during comparison."
Ah....... that is my problem then. Why is it then that the file is not
excluded from synchronisation in me case? It started working fine after I
manually excluded it. Could it be that this because the Batch job I am
launching from was created on an older version of FFS?

[Zenju]

> file is not excluded from synchronisation in me case
This really shouldn't be possible. Excluding this file when scanning base
synchronization directories is hard-coded, so it's not dependent from any
configuration. If it is copied still, I'm eager to know about the
circumstances.

[zardoz35]

perhaps a solution is an option to eject usb key that will delete
Sync.ffs_lock File ?
Sorry for this reply but I search a solution for deleting this file when I
sync my pc with multiple usb key

[Zenju]

The lock file is only excluded when residing in synchronization base
directories. May this be the problem here: The lock file is located in a
subdirectory and thous visible during another synchronization?
I don't know the details of your synchronization scenario, but this would be
the only explanation I could think of why the lock file participates in sync.

[zardoz35]

I Sync personnal data with 2 usb key
I do the firs one, eject the key (lock file is created), insert the second key
and syns again (lock file is created too)
Everedy day I sync my data. The next day freefilesync show these lock files...
Is it clear for you ?

[Zenju]

> I do the firs one, eject the key (lock file is created)
Alright, lock file is deleted when folder is not accessed anymore. You eject
the USB stick before closing FFS, so it leaves a lock file behind. This is
expected (but shouldn't cause any issues)

>The next day freefilesync show these lock files...
Do you mean show they are shown on main grid after comparison?

[zardoz35]

yes, I eject usb before closing FFS : the issue is that when the next day FFS
running, lock is present : the issue is a the lock file present in the
destination directorie

the file is not show by FFS but is present in the destination

I confirm : reloading configuration delete this file

[aiadi]

"May this be the problem here: The lock file is located in a subdirectory and
thus visible during another synchronization? "

I think that you are on the right track here. My residual file is in a
subdirectory being synchronised within a diectory that is also being
syncronised.

[zardoz35]

the only problem is this residual file in FFS 3.11
the only ways to delete are : close FFS before eject usb stick / reload FFS
config (same or different *ffs_gui)
I only use mirror option

[Zenju]

> the only ways to delete are : close FFS before eject
Yes. On the other hand there isn't any functional restriction and it's pure
existence shouldn't really hurt.

> My residual file is in a subdirectory
I'll see what I can do about this issue. But in general this is an indication
that two synchronizations are running at the same time, I'd suggest to check
how this can happen.

[zardoz35]

In my case I sync in directory A only some subdirectories
for exemple A\A1 A\A3 and A\A5 by adding them in filtering in the include
field and nothing exclude
So all others subdirectories are not sync

[Zenju]

Implemented new feature for v3.12:
Automatically exclude database and lock files from all directories (not only
from base)

[mackconsult]

I have the same problem from a laptop to a QNAP TS259. Every directory that
syncs leaves behind multiple loc files

![](http://www.mackconsult.com/wp-content/uploads/2011/11/loc files
14nov2011.jpg)

[mackconsult]

[404, Invalid URL: http://24.22.111.106/wordpress/wp-content/uploads/2011/11/loc_files14nov2011.jpg]

[Zenju]

Maybe there is some problem deleting files:
http://forums.linn.co.uk/bb/showthread.php?tid=2148
Are you using a recent firmware?

[mackconsult]

Yes mine is a QNAP TS259 and it has the most recent firmware installed. The
weird thing is that the ffs_lock files are on both my laptop and on the NAS.
Can't delete the files on either side .... even in a kornshell .....

[mackconsult]

Also the laptop is freshly built with XP and I used allsync and it copied the
ffslock files over to the laptop on the first sync from the NAS.

[Zenju]

>weird thing is that the ffs_lock files are on both my laptop and on the NAS
What error do you get when you try to delete these files manually (on NAS and
laptop)?
You may use FreeFileSync manual deletion in order to get a useful error code
instead of a generic error message. However FreeFileSync does not list
*.ffs_lock files by default, so you would first have to rename them to have
some other ending.

Did you check the NTFS security permissions of the synchronization root
folder? Maybe they prevent deletion, but allow creation of files.

[mackconsult]

When I try to delete them nothing happens. In Kornshell rm says error can't
delete link.

[Zenju]

>When I try to delete them nothing happens
You mean, you renamed them in order to see them in FreeFileSync, then deleted
them manually in FreeFileSync and it was shown as a success, i.e. the file is
shown as deleted, although it is physically existing?

[mackconsult]

I rebuilt the laptop. Just installed the freefilesync application. When I do
an analyze it is taking for ever .... says

Waiting while directory is locked .... it spends about 30 seconds on each of
these lock files ....

[Zenju]

There are two main reasons, why deletion could fail: 1. NTFS permission are
setup to prevent deletion. This can be checked out via Windows explorer
file/directory properties. 2. the NAS is setup to prevent file deletion. There
may be a setting in the web interface.

[mackconsult]

Ok, I will look into it. I am just going to rebuild the laptop again because
its giving me other issues like not being able to manually delete a folder.

Can you explain to me again why does the sync software put all those lock
files in the directory? Is there a way to have it not do this?

I am the only one that uses the server so locking it is not really necessary.

[mackconsult]

So I created a two temp folders. One in my documents on the laptop, and the
other on the Data share of my QNAP server.

Put two txt files in the temp on the laptop and then tried to setup and run a
sync. Here is the error I get .....

Keep in mind that I can access the network drives in windows no problem ....

[404, Invalid URL: http://24.22.111.106/wordpress/wp-content/uploads/2011/11/sync_error.jpg]

[Zenju]

Could you re-post the picture with the error message? The use of the locking
file is to prevent two instances of FFS from operating on the same data set in
the sense of a data race-condition, i.e. read + write or multiple write
accesses.
Generally, in order to fix this behavior, we need to find out, why
FreeFileSync isn't able to delete the file. This could be due to FFS falsely
not detecting the to be deleted file or some permissions problem. To find out,
the best test is to manually delete a file via the graphical interface.
Problem is, that this will try to create the locking file. A workaround is to
create a dummy directory somewhere and place a symbolic link to the actual
target directory.

[mackconsult]

Picture will be back up in a while. I rebuilt my server with different volume
configuration to take some encryption load out of the web server.