I really like freefilesync. Everything works pretty well.
I just run into one problem. My NAS server somehow uses a compression. If I sync all files with my NAS and resync few hours later some files on my NAS are 4096Bytes smaller than on my PC. I can resync and download those files from my NAS, but still the files on my PC are bigger.
If I compare both files in binary mode, both files are abolutly identically. If I copy a single file from my NAS to my PC via explorer and the file gets bigger. So it looks like my NAS somehow changes the file size by 4096 bytes.
So a binary compare should solve the problem, because here FreeFileSync should copy the file and binary compare both files. But I think, because it checks also the listed file size, it detects a difference, altough there should not be any difference.
Is there any way of getting rid of this problem? Adding some tollerance in file size?
File size differ 4096 Byte
- Posts: 9
- Joined: 22 May 2020
- Attachments
-
- Unbenannt.png (26.54 KiB) Viewed 4830 times
- Posts: 4056
- Joined: 11 Jun 2019
I would look into the NAS side of this issue before putting a band-aid on
- Posts: 9
- Joined: 22 May 2020
I'm not able to change any settings on the network drive. So I prefer a band-aid, if possible.
- Posts: 4056
- Joined: 11 Jun 2019
You can't change settings on your NAS? And you want a feature be developed for a single occurrence of an issue?
- Posts: 9
- Joined: 22 May 2020
It is a central managed network drive, so not my personally owned NAS and therefore I don't have access to the settings. I expected that some cloud services may behave comparable. So I searched google few hours to find a way to get around of this file difference. But I didn't find any comparable case and therefore no solution.
Have you ever heard of such a behavior?
I also wanted to check, whether there is an easy way of setting up FreeFileSync to handle this special case. I don't expected to get a new feature developed.
If you don't see any possibility to solve the problem here at FFS, do you know a better place to ask this question?
Have you ever heard of such a behavior?
I also wanted to check, whether there is an easy way of setting up FreeFileSync to handle this special case. I don't expected to get a new feature developed.
If you don't see any possibility to solve the problem here at FFS, do you know a better place to ask this question?
- Posts: 4056
- Joined: 11 Jun 2019
Gotcha, that makes more sense! I would wager that the NAS has security logging or something similar enabled that attaches a header to each file. I would also guess that the NAS strips is off when the files gets pulled off. Not sure of the best way to get around it unfortunately.
- Posts: 9
- Joined: 22 May 2020
But it is even the opposite. Files on the NAS are 4096Byte smaller.
- Posts: 9
- Joined: 22 May 2020
Someone else has an idea, where to look or how to handle the issue?
- Posts: 3
- Joined: 7 Jun 2020
Contact the admin of your NAS and the company who made this NAS? It sounds like a bug in the NAS software.
- Posts: 1037
- Joined: 8 May 2006
What NAS?
What is its' sector size?
What is your (local) disk sector size?
IOW, it does take "a few hours" before size changes?
Kind of odd that a file size change would occur (which doesn't seem right to me, anyhow), without touching date/time. (Though I would expect a sane program to be able to maintain date/time of a changed file - in particular circumstances.)
If you make a copy of the backup job, & instead of saving it to the NAS, save it to another directory, locally, will the same file size mismatch occur?
If you explore these files from Windows Explorer (&/or a third-party file manager) does it too show these 4096 differences, or is it only FFS that sees it this way?
What is its' sector size?
What is your (local) disk sector size?
If you sync, them immediately Compare, does it find no changes?few hours later some files on my NAS are 4096Bytes smaller than on my PC
IOW, it does take "a few hours" before size changes?
Kind of odd that a file size change would occur (which doesn't seem right to me, anyhow), without touching date/time. (Though I would expect a sane program to be able to maintain date/time of a changed file - in particular circumstances.)
If you make a copy of the backup job, & instead of saving it to the NAS, save it to another directory, locally, will the same file size mismatch occur?
Any ideas as to why only some files are affected?some files on my NAS are 4096Bytes smaller than on my PC
If you explore these files from Windows Explorer (&/or a third-party file manager) does it too show these 4096 differences, or is it only FFS that sees it this way?
- Posts: 9
- Joined: 22 May 2020
It is a managed Network Storage by Atos. So I don't know, what server they are using, if they compress the files and what Sector Size they are using. But If I get it right, it should not influence the file size, just the used size on the hard drive.
The hint about doing a local backup directory, was a good one.
I used an external SSD (exFAT) to backup the files, and the same behavior occurs. So it looks like it's not the NAS which is doing bad things, but my win10 with my build in ssd.
Syncing from NAS to external SSD works well, without any changes in file size.
I don't see a pattern in the files, which are changed in file size. Specially on small files, with only few bytes it looks worse, e.g. 693Bytes become 4791Bytes on my local ssd.
On my PC is an AV installed and Bitlocker was enabled. Disabling it on this partition didn't change anything.
Any other hint, what could cause this behavior?
The hint about doing a local backup directory, was a good one.
I used an external SSD (exFAT) to backup the files, and the same behavior occurs. So it looks like it's not the NAS which is doing bad things, but my win10 with my build in ssd.
Syncing from NAS to external SSD works well, without any changes in file size.
I don't see a pattern in the files, which are changed in file size. Specially on small files, with only few bytes it looks worse, e.g. 693Bytes become 4791Bytes on my local ssd.
On my PC is an AV installed and Bitlocker was enabled. Disabling it on this partition didn't change anything.
Any other hint, what could cause this behavior?
- Posts: 1037
- Joined: 8 May 2006
Are the files in question open by some other program?
I have a program that uses a license manager.
License Manager opens a log file.
Log file that was backed up is the size - at some point in time - but smaller then what exists (currently) on disk (the source file).
I get something like this (rather continuously):
I'm thinking, that perhaps once a day (once the day changes, so from 18th to 19th, to 20th), something gets written, sync'd if you will, such that a "file change" is "recorded", & at that point, FFS will then pick up that change & write it out to the backup. (But throughout the day, it, its logs, only note that something is amiss.) (License manager typically runs 24/7... If it were to be shut down, I'm sure the change would be picked up immediately.)
(Similarly, but slightly differently, again, Everything (which reads from the MFT) has the particular file size & date/time, sized, & dated the size/date that its' database initially read the file, & does not see the newer, large size, later date. I suppose, if I were to force an update, it would pick up current data size/date & hold that from that point on... or until some action occurred "releasing" the file, at which point all would update, automatically.)
I have a program that uses a license manager.
License Manager opens a log file.
Log file that was backed up is the size - at some point in time - but smaller then what exists (currently) on disk (the source file).
I get something like this (rather continuously):
[12:20:21 PM] Warning: The following items have unresolved conflicts and will not be synchronized:
Folder pair: C:\BASIS <-> \\Nas\Complete Database Backup\BASIS
BASIS License Manager\blmgr.txt: Files have the same date but a different size.
<- Date: 06/19/2020 10:34:34 AM Size: 3,114
-> Date: 06/19/2020 10:34:34 AM Size: 2,765
(Similarly, but slightly differently, again, Everything (which reads from the MFT) has the particular file size & date/time, sized, & dated the size/date that its' database initially read the file, & does not see the newer, large size, later date. I suppose, if I were to force an update, it would pick up current data size/date & hold that from that point on... or until some action occurred "releasing" the file, at which point all would update, automatically.)
- Posts: 9
- Joined: 22 May 2020
No, I don't see any programm, which should change the files. Because this arn't special files and not just one single one but many files are changed and the date stays unchanged. Just size differs.
- Posts: 9
- Joined: 22 May 2020
I conducted some other tests. I have two different SSDs installed in my PC (Samsung, Intel) and the behavior is on both the same. If I use external devices this does not happen. So I strongly belive it's the virus scanner, which does not scans external drives.
Has anyone an idea, how to define an internal ssd as an external device? I don't have access to my virus scanner options. So using an external definition would be the easiest way.
Has anyone an idea, how to define an internal ssd as an external device? I don't have access to my virus scanner options. So using an external definition would be the easiest way.
- Posts: 1037
- Joined: 8 May 2006
Thinking these have some relevance:
[Macrium] This article explains the reasons why you might see the error message "Incompatible Disk Selected" when attempting a Restore or Clone operation.
What's the point of hard drives reporting their physical sector size?
Do hard disk drives turn on 512e (512byte emulation of 4k sectors) as-needed depending on host controller?
[Macrium] This article explains the reasons why you might see the error message "Incompatible Disk Selected" when attempting a Restore or Clone operation.
What's the point of hard drives reporting their physical sector size?
Do hard disk drives turn on 512e (512byte emulation of 4k sectors) as-needed depending on host controller?