First time user.
I just installed FreeFileSync and I'm comparing between two folders. One
folder is the original folder and the other is a backup folder which should
actually mirror the original. The Original folder resides on my laptop hard
drive (running Windows XP SP3). The backup is on an external usb hard drive.
Currently both folders on either end should be exactly the same except for a
few recent additions to the original folder.
I expected FreeFileSync to detect those few files as new additions and suggest
that I copy them over to the backup folder on the external drive.
In actuality, it did this. But it also made many more suggestions of copying
files from my ORIGINALS to my BACKUP which I absolutely knew already existed
there. Moreover, FreeFileSync actually claimed that files on my BACKUP do not
exist on my ORIGINALS and recommended I copy those over to my ORIGINALS
folder.
Checking this issue more closely, I realized that these files (which I
believed didn't require syncing) actually DO exist on both drives identically.
For some strange reason FreeFileSync registered these files as being slightly
different in file size and this is the reason that it identifies them as being
different files. Yet Windows Explorer shows these files to be exactly the same
in file size!
So a few questions:
1. Why is FreeFileSync registering a different file size compared to Windows Explorer?
2. Assuming there is a reasonable answer to why this is happening, how do I prevent it?
3. Is there a way for FreeFileSync to identify when two files are very similar but just slightly different and may in fact just be two very slightly different versions of the same file? Or is that the task for a different program?
Looking forward to your reply
Same file - but in FFS different file size?!
- Posts: 1
- Joined: 12 Jan 2011
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
> Yet Windows Explorer shows these files to be exactly the same in file size!
Can you send a few screenshots describing this (mis)behavior? In general there
is very little chance, FFS doesn't work correctly for such a basic task.
>1. Why is FreeFileSync registering a different file size compared to Windows
Explorer?
There is no difference.
> 3. Is there a way for FreeFileSync to identify when two files are very
similar
Depends on what you would consider "similar". FreeFileSync with default
comparison variant treats files as equal that have the same name, size and
modification date. This is virtually equivalent to being binary equal, which
is almost always what is required when synchronizing.
Can you send a few screenshots describing this (mis)behavior? In general there
is very little chance, FFS doesn't work correctly for such a basic task.
>1. Why is FreeFileSync registering a different file size compared to Windows
Explorer?
There is no difference.
> 3. Is there a way for FreeFileSync to identify when two files are very
similar
Depends on what you would consider "similar". FreeFileSync with default
comparison variant treats files as equal that have the same name, size and
modification date. This is virtually equivalent to being binary equal, which
is almost always what is required when synchronizing.
- Posts: 3
- Joined: 5 Aug 2015
I'm having the same trouble with version 7.2.
The log reports:
"FILES\157-JAN2.FLD\10259w149th.ZAP": Files "FILES\157-JAN2.FLD\10259w149th.ZAP" have the same date but a different size.
<-- Date: 1/9/2015 12:01:46 PM Size: 5,086,839
--> Date: 1/9/2015 12:01:46 PM Size: 5,086,854
However, Windows 7 reports the two files with the exact same size (5,086,839).
So, what gives?
The log reports:
"FILES\157-JAN2.FLD\10259w149th.ZAP": Files "FILES\157-JAN2.FLD\10259w149th.ZAP" have the same date but a different size.
<-- Date: 1/9/2015 12:01:46 PM Size: 5,086,839
--> Date: 1/9/2015 12:01:46 PM Size: 5,086,854
However, Windows 7 reports the two files with the exact same size (5,086,839).
So, what gives?
- Attachments
-
- ZAPproperties.png (18.6 KiB) Viewed 2752 times
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
Is this issue reproducible or just some temporary issue (e.g. one file was changed after comparing with FFS)?
- Posts: 23
- Joined: 15 Aug 2009
> treats files as equal that have the same name, size and
modification date. This is virtually equivalent to being binary equal,
as there is software that changes file modification time, that statement is not necessarily correct.
I think that is why one sometimes needs binary comparison.
Klaus
modification date. This is virtually equivalent to being binary equal,
as there is software that changes file modification time, that statement is not necessarily correct.
I think that is why one sometimes needs binary comparison.
Klaus
- Posts: 3
- Joined: 5 Aug 2015
As you can see in the log, the modification dates are exactly the same. The file on the backup device was created by FFS earlier this week and neither file has been changed since.Is this issue reproducible or just some temporary issue (e.g. one file was changed after comparing with FFS)?Zenju
I reran FFS yesterday to confirm the errors in the log and, once I saw the same error messages, I immediately started investigating and discovered the discrepency in the reported file size.
FFS reports the file on the backup device as bigger than how Windows reports it, regardless of any modification of either file.
The source file is on an NTFS volume on a Windows 7 computer and the backup file is on a USB 3.5" Seagate NTFS drive. Does FAT32 report file sizes differently than NTFS? If so, I need to confirm that the backup device is indeed NTFS as I remember it being. Hmmm.... the size we're comparing is the actual size not the "size on disk" so that may not be the problem.
Anyway, this is as yet unresolved and the user is getting a bad impression of FFS.
Thank you.
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
So you are able to reproduce this discrepancy? In this case we could investigate further.As you can see in the log, the modification dates are exactly the same. The file on the backup device was created by FFS earlier this week and neither file has been changed since.
I reran FFS yesterday to confirm the errors in the log and, once I saw the same error messages, I immediately started investigating and discovered the discrepency in the reported file size.
FFS reports the file on the backup device as bigger than how Windows reports it, regardless of any modification of either file.
The source file is on an NTFS volume on a Windows 7 computer and the backup file is on a USB 3.5" Seagate NTFS drive. Does FAT32 report file sizes differently than NTFS? If so, I need to confirm that the backup device is indeed NTFS as I remember it being. Hmmm.... the size we're comparing is the actual size not the "size on disk" so that may not be the problem.
Anyway, this is as yet unresolved and the user is getting a bad impression of FFS.
Thank you.seell
- Posts: 3
- Joined: 5 Aug 2015
Yes, there are probably 3 or 4 days of logs (so far) with this error.So you are able to reproduce this discrepancy? In this case we could investigate further.Zenju
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
Do you see this discrepancy right now on the main dialog when you do a manual comparison with FreeFileSync?Yes, there are probably 3 or 4 days of logs (so far) with this error.seell
- Posts: 1
- Joined: 29 Oct 2016
Have you found a solution to this issue yet? I have the same problem. See Warning Message below:
"SonicSole MusicProd/Hooks/Hooks/Audio Files/Hooks_18#13.aif": Files "SonicSole MusicProd/Hooks/Hooks/Audio Files/Hooks_18#13.aif" have the same date but a different size.
<-- Date: 10/24/2016 16:06:22 Size: 2,151,908
--> Date: 10/24/2016 16:06:22 Size: 2,189,246
"SonicSole MusicProd/Hooks/Hooks/Audio Files/Hooks_18#13.aif": Files "SonicSole MusicProd/Hooks/Hooks/Audio Files/Hooks_18#13.aif" have the same date but a different size.
<-- Date: 10/24/2016 16:06:22 Size: 2,151,908
--> Date: 10/24/2016 16:06:22 Size: 2,189,246
- Posts: 2
- Joined: 3 Aug 2023
I have this issue as well on Mac M1 MAx, (13.2.1) in FFS (12.5) when syncing from an External SSD to "update" a RAID drive.
I'm wondering if this is an issue with the way different external drive handle files over time. Perhaps the RAID array is causing the files to lose a few bytes of data?
Could FFS add a feature to ignore discrepancies within a certain Byte threshold?
- Attachments
-
- Screenshot 2023-08-03 at 3.48.03 PM.png (256.65 KiB) Viewed 750 times
- Posts: 1038
- Joined: 8 May 2006
I would think that "over time" meta-data (tags or whatnot) have been added/changed to the files (with the file date/time being left unchanged [possibly, can't tell from the shot]).wondering if this is an issue with the way different external drive handle files over time. Perhaps the RAID array is causing the files to lose a few bytes of data?
If you run a binary compare between a set of files, does that point anything out?
(That's very odd looking to me, that fixed-width fonts are not being used.)
The target drive is the RAID drive?
So when you initially sync, the file sizes are in fact the same?over time
All files are affected or only some?
If only some, any relationship between those particular files & actions you may have performed... (doesn't make sense does it, cause you wouldn't be accessing, would you, the target files, particularly - instead, you would [normally] access the source files...)?
Might the Mac end add meta-data (of any sort) that is stripped off on the RAID end (& again that wouldn't make sense)?