Does changing source volume name break "detect moved files" (MacOS)?

[simcc]

Hi, so I have a source volume that I changed the name of and haven't backed up in a while...and it looks like detect moved files isn't working now when i do a comparison...any ideas...the sync.ffs file is on both source and destination...

Thanks.

(source volume was called "Downloadz" (/Volumes/Downloadz) and just changed it to "Downloads")

[simcc]

Tried changing the name back and no dice.

I noticed though ".sync.ffs_db" is 627KB on source and 2.9MB on destination...I wonder if it's got messed up...also created date for that file is 02/02/40 on source...but mod date/time is the same on both 23/07/23...


Is there anything I can try to fix it...rather than copy 500GB?
(maybe edit the created date or something)

[xCSxXenon]

You should have run a sync before changing the name. Then, the moves/renames would have been detected as such, and then the matching operation would be performed on the destination rather than a delete-then-recopy. If you had done that, you could have changed the name to "Downloads", then run a sync that would have no changes since it was just synced, and then the db file would have been rebuilt/corrected. The created/modified date for the sync.db files have no meaning/impact on their use.

Even in the situation you are in, only the moves/renames since your last sync would have to be propagated using the slower delete-then-recopy process. Is 500GB the total amount of data in the source or just the amount that has changed since the last sync?

[simcc]

OK cheers re "created/modified date".

Yeah 500GB has to be copied over...it's basically all stuff that was just moved around.

I think it's possible the sync.ffs on the source got messed up, or it could have been read-only at the time of last update...

[Zenju]

Changing the volume name does not impact detection of moved files, which relies on inode IDs.

Different sizes of sync.ffs_db file is not necessarily an issue. If there is any data corruption of these files, FFS would have shown an error after comparison.

[simcc]

Hi, so I just did a delete-then-recopy. But at the end I'm getting this error:

Cannot open file "/Volumes/Downloads/.AppleDB/lock".
EAGAIN: Resource temporarily unavailable [open]

Would this be anything to do with it...or should I just exclude that folder "/.AppleDB/"

[xCSxXenon]

Can't find any concrete info on what that directory is used for, so it probably has no need to be backed up. I would exclude it. It's definitely a system file location, and FFS isn't a good option for system backup/restore anyway