UPDATE mode - Files on target have been renamed lead to files on source detected as new file

[Blacknoise_21]

Hi FFS,

I'm using FFS exactly for the awesome new UPDATE mode.

However, I have noticed an inconsistent issue.

Very often but not always, after renaming a few files on the target destination, FFS detects the original files on the source destination as new files.

Any idea what could happen?

[Blacknoise_21]

Here is a few more info:

I'm using FFS 13.8 on a M1 2020 MacBook Air running Sonoma 14.4.1

[Zenju]

Most likely these files have been renamed *and* changed.

[Blacknoise_21]

Yes indeed, the metadata has been changed.
So do you mean it's the expected behavior?
I thought that after a file had been copied to the target destination, we could do anything to the copied file (including deleting the file), FFS would never resync the file from the source destination.

[xCSxXenon]

I guess this just brings up the debate on what a new file even is.
If a file is renamed, it isn't new.
If a file is changed/updated, it isn't new.
So if a file is renamed and changed, is it new? I wouldn't say so. I wonder if the file IDs that are used for 'renamed/moved' files can be used in the same way.

[therube]

I thought that after a file had been copied to the target destination, we could do anything to the copied file (including deleting the file), FFS would never resync the file from the source destination.

To accomplish something like that, you would need to move the source file out of the source directory after the Update (to target) took place.

[Blacknoise_21]

Thanks for the details.
I can't proceed with this @therube as those files are shared with clients and colleagues.

So in my situation, FFS would be effective if it had an additional mode that utilizes the database file to verify if the file has already been copied.
If so, it would then be skipped.

Does anyone know of a tool that provides this kind of synchronization workflow?

[Blacknoise_21]

I wonder if it could be implemented in the future as it seems like a pretty easy feature to add.
(I might be wrong by missing a few edge cases…)

[therube]

If there were an Attribute check (there is not), if removing the +A (archive) attribute from a (source) file after Update were an option, if the source file were then left unchanged, then you could do something like IF -A (archive attrib is not set), then skip file...

(But that is not available.)


Resetting archive attribute on copied files

[Blacknoise_21]

Yes @therube, that seems like an excellent solution.
As I am relatively new to FFS, do you believe there are good chances that this will be implemented fairly soon? What is the procedure for suggesting a new feature? Does the developer frequently monitor this forum?

Thank you very much for your assistance.