NTFS to NTFS via SMB Move Detection Not Working?

Get help for specific problems
Posts: 13
Joined: 30 Mar 2020

nmkaufman

FFS 10.22 Donation Edition 64Bit

Both source and destination folders are NTFS.

I'm using Windows File Sharing (SMB) to connect one computer to the other.

I'm using the UNC to point to the remote folder (but I've also tried mapping.)

I'm using 'mirror' with rename detection enabled.

I have read/write access to both disks.

The sync.ffs_db files are being created/updated on both disks.

I've tried renaming both files and folders, and it re-uploads the files every time.

Is there a way to enable more robust logging, to see what's happening?
User avatar
Site Admin
Posts: 7047
Joined: 9 Dec 2007

Zenju

Posts: 13
Joined: 30 Mar 2020

nmkaufman

Thank you!

I was testing last night, and I think it has to do with the depth of synced folders.

I will try the beta, and see what it tells me.
Posts: 13
Joined: 30 Mar 2020

nmkaufman

I'm still not seeing any evidence that it's actually trying to compare.

I think it's just silently failing because the folders are too deep.

Nevermind, I can't seem to get it to work, now.

I'll report back if I figure anything out.
Attachments
Move Test.html
(8.46 KiB) Downloaded 75 times
Rename Test.html
(8.28 KiB) Downloaded 73 times
User avatar
Site Admin
Posts: 7047
Joined: 9 Dec 2007

Zenju

No error? Interesting. Here's a "hacked" FFS version that displays the file id in the column that normally would show the file size:
https://www.mediafire.com/file/8uy8mcuz2me1rzc/FreeFileSync_10.26_%5BBeta%5D_Windows_Setup.exe

First, synchronize both folders. Then pick one of the files and note the file ids (use CTRL + C) on both sides. Rename it. Compare again with FFS and check if the file IDs are still the same, despite the renaming operation. If so, FFS should offer to move instead of copy/delete.
Posts: 13
Joined: 30 Mar 2020

nmkaufman

Interesting, now we're getting somewhere.

It looks like it might be a problem with Drivepool, and not FreeFileSync.

Something is causing the File ID to change, but only in certain circumstances.

I've attached a successful rename (test >Test) and a failure (Test > Rename).

I'll try making a post on their forum, to see if this is expected behavior.
Attachments
success.png
success.png (33.14 KiB) Viewed 2057 times
failure.png
failure.png (50.32 KiB) Viewed 2057 times
Posts: 13
Joined: 30 Mar 2020

nmkaufman

This is definitely Drivepool's fault, I've attached another screengrab to illustrate.

Thanks again, for all the help. I would have never figured this out, otherwise.
Attachments
Annotation 2020-06-26 123938.png
Annotation 2020-06-26 123938.png (22.43 KiB) Viewed 2035 times
User avatar
Posts: 2267
Joined: 22 Aug 2012

Plerry

... a successful rename (test >Test) ...nmkaufman, 25 Jun 2020, 18:27
You have to be careful here!
In a Windows environment (CIFS/SMB), capatilization in folder- and file-names is essentially ignored.
Windows will e.g. gladly open a file Test.txt when opened as test.txt or vice-versa.
So, such a test >Test rename may also be ignored by Drivepool.
Posts: 939
Joined: 8 May 2006

therube

(A little bit on Case Sensitive.)

For reference, DrivePool.