Each time I start the synchronize job most of the files differ from size
between source and destination, allthough most of them haven't changed. So,
normally 300 files have to be copied, the numer increases to 2500 or more,
allthough only 300 files are changed.
File size constantly differs
- Posts: 1
- Joined: 6 Nov 2011
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
FreeFileSync doesn't change file sizes in any way. Some storage providers save
additional metadata at the end of each file, this could be the problem here.
additional metadata at the end of each file, this could be the problem here.
- Posts: 1
- Joined: 8 Dec 2011
Hello,
I'm having the same issue. I don't think it's related to a storage provider,
because it just happens on a local network sync.
Setup:
Local machine: A Windows 7 PC
Network drive: A samba share on a linux server
Sometimes FreeFileSync reports that the files differ in size (indicated by a
flash symbol), but the files on both sides are correct - I can verify this,
e.g. by opening them or by doing a binary compare.
I found that it's related to the two different sizes Win7 (or XP) reports when
you show the properties of the file (the "left", local file).
One size reports the "real" file size, the other reports the files size used
on disk. This occurs because of the cluster size on an NTFS volume. So the
size on disk can be bigger than the real file size, because it reports the
number of clusters * clustersize.
Now, I assume that's not a bug, but it precludes me from synching folders,
because this issue never disappears, and there's no chance to force the
synchonization.
(Or, maybe it is a bug - is it intentionally that FFS sometimes uses the
"space on disk" value as the file size? Isn't that useless?)
A suggestion:
Could you read out both file sizes (the real size and the size on disk) and
compare if at least one of them matches the size on the other side? Or at
least give an option to this behavior in the sync settings?
Both files on both sides show identical date and time, by the way.
Besides that, great software!
I'm having the same issue. I don't think it's related to a storage provider,
because it just happens on a local network sync.
Setup:
Local machine: A Windows 7 PC
Network drive: A samba share on a linux server
Sometimes FreeFileSync reports that the files differ in size (indicated by a
flash symbol), but the files on both sides are correct - I can verify this,
e.g. by opening them or by doing a binary compare.
I found that it's related to the two different sizes Win7 (or XP) reports when
you show the properties of the file (the "left", local file).
One size reports the "real" file size, the other reports the files size used
on disk. This occurs because of the cluster size on an NTFS volume. So the
size on disk can be bigger than the real file size, because it reports the
number of clusters * clustersize.
Now, I assume that's not a bug, but it precludes me from synching folders,
because this issue never disappears, and there's no chance to force the
synchonization.
(Or, maybe it is a bug - is it intentionally that FFS sometimes uses the
"space on disk" value as the file size? Isn't that useless?)
A suggestion:
Could you read out both file sizes (the real size and the size on disk) and
compare if at least one of them matches the size on the other side? Or at
least give an option to this behavior in the sync settings?
Both files on both sides show identical date and time, by the way.
Besides that, great software!
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
FreeFileSync retrieves the file sizes from FindFirstFile
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365740%28v=vs.85%29.aspx.
This always gives the logical size of a file, not the physical one. If there
is a mismatch on both sides, although you are sure the files are binary
identical, then this could be a bug in the implementation of the file system
abstraction layer.
Or the implementations of Windows 7 and Samba can't agree what filesize
actually means: Does filesize include the sum of all alternate data streams?
In any case, this needs to be solved at a lower level than FreeFileSync
(=Win32 API level)
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365740%28v=vs.85%29.aspx.
This always gives the logical size of a file, not the physical one. If there
is a mismatch on both sides, although you are sure the files are binary
identical, then this could be a bug in the implementation of the file system
abstraction layer.
Or the implementations of Windows 7 and Samba can't agree what filesize
actually means: Does filesize include the sum of all alternate data streams?
In any case, this needs to be solved at a lower level than FreeFileSync
(=Win32 API level)
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
BTW, no matter how the file system calculates filesizes, FreeFileSync should
*always* display the same number that is also seen in Windows Explorer.
*always* display the same number that is also seen in Windows Explorer.
- Posts: 2
- Joined: 7 May 2012
Same problem for me I guess.
Accessing a Lacie Network Space 2 from Windows Server 2008 R2.
Just comparing files seems to change file size.
Example:
38byte file copied to NAS. Yes it is no 38byte on NAS.
After just comparing it is 512byte. Different size.
Maybe a SAMBA problem.
Workaround?
Accessing a Lacie Network Space 2 from Windows Server 2008 R2.
Just comparing files seems to change file size.
Example:
38byte file copied to NAS. Yes it is no 38byte on NAS.
After just comparing it is 512byte. Different size.
Maybe a SAMBA problem.
Workaround?
- Posts: 2
- Joined: 7 May 2012
Example:
1. 38byte file copied to NAS. Yes it is no 38byte on NAS.
2. Comparing results in no differens. OK!
3. After a new compare it is 512byte. Different size.
1. 38byte file copied to NAS. Yes it is no 38byte on NAS.
2. Comparing results in no differens. OK!
3. After a new compare it is 512byte. Different size.
- Posts: 2
- Joined: 12 Nov 2022
Can you please consider to make following possibility in FreeFileSync:
- Comparision -> File time ?
(Presently, only "File size", "File time and size" and "File content" comparision methods exist, so it is not possible to compare only with file-time. Remark: when I compare using "File content" I have the same problem as described in previous posts.)
- Comparision -> File time ?
(Presently, only "File size", "File time and size" and "File content" comparision methods exist, so it is not possible to compare only with file-time. Remark: when I compare using "File content" I have the same problem as described in previous posts.)
- Posts: 1
- Joined: 13 Nov 2022
This theme still active?
- Posts: 1038
- Joined: 8 May 2006
@Planinkovic
And if different (& assuming there has not been actual file corruption), what is the target end that you are copying to?
Have you verified that in fact the files are different (by hash or otherwise)?when I compare using "File content"
And if different (& assuming there has not been actual file corruption), what is the target end that you are copying to?
- Posts: 2
- Joined: 12 Nov 2022
Hello,
After I've checked precisly, I found that I have, by mistake, changed my source and target directory - this is the reason why I had the problem - but I only figured it now; I was also confused looking in windows-properties of the file thinking that size is different in the source and target directory for some particular file.. Anyway now it is working ok; I appologise for inconvenience, and thank you for your time.
Regards
After I've checked precisly, I found that I have, by mistake, changed my source and target directory - this is the reason why I had the problem - but I only figured it now; I was also confused looking in windows-properties of the file thinking that size is different in the source and target directory for some particular file.. Anyway now it is working ok; I appologise for inconvenience, and thank you for your time.
Regards
