Idea for detecting moved files in non-NTFS file systems

[maykelbembibre]

FreeFileSync could have a basic embedded file explorer such that if you use it to rename or move a file or folder it automatically records the action in the FreeFileSync database. This way, even if the file systems of the drives are not NTFS, FreeFileSync could efficiently replicate file moves on the drive on the right.

[Plerry]

FFS does not require the file system to be NTFS to efficiently replicate file renames or moves.
In order to efficiently replicate file renames or moves, FFS requires the left and right location to have stable, cross session file IDs.

[favoredrive]

Try https://github.com/239/euaie, worked for me on exFAT.

[maykelbembibre]

FFS does not require the file system to be NTFS to efficiently replicate file renames or moves.
In order to efficiently replicate file renames or moves, FFS requires the left and right location to have stable, cross session file IDs.

But according to the documentation, FAT file systems don't have stable file IDs, and those file systems are precisely the ones I need to use for compatibility with my phone.

[xCSxXenon]

What is you make a change in FFS, but then something outside FFS makes another change? How does FFS handle such a scenario? On top of bloating FFS with a File Manager, not being able to guarantee the state of the files is reason enough not to implement such thing.

[maykelbembibre]

What is you make a change in FFS, but then something outside FFS makes another change? How does FFS handle such a scenario? On top of bloating FFS with a File Manager, not being able to guarantee the state of the files is reason enough not to implement such thing.

Well in that case the solution wouldn't work. But the problem remains that whenever I rename or move files or folders in my primary storage medium, having to replicate those operations in the secondary medium is a pain in the arse.

[favoredrive]

That is exactly the reason I use euaie left/ right/ -t 2000 for my media collection...

[xCSxXenon]

What is you make a change in FFS, but then something outside FFS makes another change? How does FFS handle such a scenario? On top of bloating FFS with a File Manager, not being able to guarantee the state of the files is reason enough not to implement such thing.

Well in that case the solution wouldn't work. But the problem remains that whenever I rename or move files or folders in my primary storage medium, having to replicate those operations in the secondary medium is a pain in the arse.

Not really a problem, it just takes longer to recopy data than move it. FFS handles everything for you, you don't have to replicate it manually, so it can't be a painpoint in the first place

[maykelbembibre]

What is you make a change in FFS, but then something outside FFS makes another change? How does FFS handle such a scenario? On top of bloating FFS with a File Manager, not being able to guarantee the state of the files is reason enough not to implement such thing.

Well in that case the solution wouldn't work. But the problem remains that whenever I rename or move files or folders in my primary storage medium, having to replicate those operations in the secondary medium is a pain in the arse.

Not really a problem, it just takes longer to recopy data than move it. FFS handles everything for you, you don't have to replicate it manually, so it can't be a painpoint in the first place

True, but in case byte corruption happened on the drive on the left, it would be propagated to the right in those recopies maybe just because a folder had been renamed.

[xCSxXenon]

Proper backup strategy is the solution to that