FFS_LOCK files should not be created in monitored folders [IMPLEMENTED]

[Synchronizator]

Every now and then I stumble upon a sync.FFS_LOCK file. Users should not care if this is a leftover due to a forced system reset, an overlapping with simultaneously running program like BackUp Maker or some bug of FFS / RTS - instead this issue should be dealt with swiftly by making just one such file and by storing it in e.g.

C:\Users\YOUR-USER-NAME\AppData\Roaming\FreeFileSync


This is especially annoying when a user monitors

C:\Users\YOUR-USER-NAME\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

and after booting up is once again greeted by Windows with a pop-up window informing of lack of association with FFS_LOCK file format

[xCSxXenon]

That makes no sense and you have no clue what these lock files are for. I don't even want to try explaining because you seem to be here simply to disagree with every implementation of every feature. The lock file is to prevent multiple FFS sessions from interacting with the same location, putting it in the AppData folder is useless

[Synchronizator]

Yes, you are absolutely correct: whenever I see a forum for a program I register on it, download its program and start using it - only for the sole purpose of posting extensive critique of its every element, going systematically feature-by-feature, option-by-option, window-by-window. That said: please post a list of forums that you know of, because I have too much time to waste it just on this one. Preferably mark those forums on which you yourself are present, so that I will do my best to try extra annoy you with my questions and suggestions


As for the sync.FFS_LOCK files, I see no reason why they should not be at least created with the hidden parameter applied to them, so that they would stop popping into existence always visibly to users whenever they are exploring their monitored locations. For example LibreOffice does so [at least with files opened in LibreWriter] - thus a user can avoid seeing them if a user wishes so [by choosing to conceal all of hidden files]

As for the multiple sessions issue: should it no be up to user to avoid such conflicts? If user runs just one instance- then this issue should not exist in the fist place; I reckon. If user however runs multiple instances- then such person should well know what is doing and what havoc it can wreak when done without a careful thought. And if multiple users are syncing the same location at the same time- should it not be up to the administrator to control this [and again with just one instance]?

[Plerry]

The topic of the location of ffs-lock files has been discussed already several times in this forum.
The fact that Synchronizator brings it up again means (s?)he has not applied due diligence.

And I agree with the trend in xCSxXenon reaction above.
Synchronizator is an apparently new user that, without having built up any serious experience in how to use FFS and RTS and having developed best practices, floods this forum with as much change request as the number of sync configurations (s?)he thinks (s?)he needs.

I am reacting in this forum out of appreciation for the fine software that I consider FFS and RTS to be.
But in order to prevent further frustration/annoyment on my end I will no longer react to Synchronizator's posts or reactions.

[Synchronizator]

Could it be that recurring suggestions can mean something else than lack of due diligence from new and old users? No, it surely cannot be. At least not in minds of some those later ones


I cannot stop being continuously distracted with sync.FFS_LOCK file popping into existence in heavily used by me

C:\Users\YOUR-USER-NAME\Documents

folder by ordering it to be created as hidden and I cannot have a real time non-disruptive backup of

C:\Users\YOUR-USER-NAME\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

system folder by changing location of the sync.FFS_LOCK file assigned to this folder - and I am also unable to utilize for both of them a simple trick of monitoring the whole

C:\Users\YOUR-USER-NAME\

folder, because RTS will spit out a window informing about it not being able to copy e.g.

C:\Users\YOUR-USER-NAME\AppData\Local\Microsoft\WindowsApps\MicrosoftEdge.exe

and

C:\Users\YOUR-USER-NAME\AppData\Local\Microsoft\WindowsApps\python.exe

So how else can this be worked around?

[Zenju]

different location:
Wouldn't make sense for a lock file that is supposed to also protect a network location that can be accessed by multiple users

user-option to disable:
Currently they can only be disabled globally. Ideally this option should be at a folder pair level, so that users can disable them, when they are (a) not needed, and (b) cause problems, e.g. needless warnings. This is still a ToDo.

create hidden:
Can't think of a reason why not. Lock files for the next FFS release will be created with the hidden attribute!

[Plerry]

create hidden:
Can't think of a reason why not. Lock files for the next FFS release will be created with the hidden attribute!

I am not in favor of this change.
I can think of a very clear reason not to make lock-files hidden:
The default Windows setting is to have hidden files invisible.
And I suppose most people leave it like that; possibly most out of ignorance, but some deliberately.
If you then need to remove a FFS lock-file manually, looking for the lock-file you will not be able to find it, unless you realize it is a hidden file and that you need to make hidden files visible ...

[xCSxXenon]

create hidden:
Can't think of a reason why not. Lock files for the next FFS release will be created with the hidden attribute!

I am not in favor of this change.
I can think of a very clear reason not to make lock-files hidden:
The default Windows setting is to have hidden files invisible.
And I suppose most people leave it like that; possibly most out of ignorance, but some deliberately.
If you then need to remove a FFS lock-file manually, looking for the lock-file you will not be able to find it, unless you realize it is a hidden file and that you need to make hidden files visible ...

To be fair, FFS is able to detect abandoned lock files and remove them automatically. It should be rare to never that you have to manually delete them

[Synchronizator]

different location:
Wouldn't make sense for a lock file that is supposed to also protect a network location that can be accessed by multiple users

That is what I was suspecting

user-option to disable:
Currently they can only be disabled globally. Ideally this option should be at a folder pair level, so that users can disable them, when they are (a) not needed, and (b) cause problems, e.g. needless warnings. This is still a ToDo.

This would take care of my problem - why also allowing other users who do use network locations to retain protection [by default] where needed

create hidden:
Can't think of a reason why not. Lock files for the next FFS release will be created with the hidden attribute!

Looking forward to, as it will immediately alleviate that small constant annoyance

[...]
I can think of a very clear reason not to make lock-files hidden:
[...]
If you then need to remove a FFS lock-file manually, looking for the lock-file you will not be able to find it, unless you realize it is a hidden file and that you need to make hidden files visible ...

Well currently DMP files are being created on the Desktop. It was days until I myself have discovered them despite them being not-hidden, as I do not use Desktop at all. So it would not be a fist case of FFS concealing something

I use FreeCommander in which I have placed a button for convenient turning on and off of hidden items. Whenever I check something important or look for a root cause of glitches I push that button to be sure, I am seeing everything. And I think that a person who uses a program like FFS / RTS should well know about existence of many important items that are hidden and know how to look for them

In other words: users like me are forced to remember that Desktop might bare such important files - while users like you will have to remember about checking for hidden files


Or to please both sides of the aisle: why not make this a user choice, letting each person decide if FFS_LOCK files should be hidden or not?

[Synchronizator]

[...]
create hidden:
Can't think of a reason why not. Lock files for the next FFS release will be created with the hidden attribute!

Has this been implemented?

I get the same behavior in 12.4 like in 12.3 version: I get to see a FFS_LOCK file for a monitored folder despite turning off in FreeCommander seeing of hidden files

[therube]

(I don't see it mentioned in the change log.)

Yes, you are absolutely correct...

Great response :-).

[Synchronizator]

I can see now [having just updated to version 13.2 from 12.4] that this has been done

So thank you