Freefilesync 3.16 corrupted files

[normahs]

I used FreeFileSync to sync two folders between my Windows Home Server and my
Desktop PC. The thing is that it corrupted the data in both folders rendering
all the files unusable. Both movies and images got corrupted. The weird thing
is that the creation date for the files are 16.06.2011 and the changed date
are 02.05.2011. All the files from that date are totally unusable.

Anyone got any suggestions to how to solve this if possible? The file sizes
are still ok, but i can't open any of the files no matter what program i try.

Filesystems are NTFS on both, copied over Gblan with FFS 3.16.

Any help would be deeply appreciated.

[Zenju]

If the files have been corrupted, then the only option is to reapply some
other backup. There is no way to repair corrupted files. FreeFileSync
internally uses Windows's standard copy routine. So the culprit needs to be
searched for in the network setup.

[hari76]

Hi Guys

@ normahs

What mode do you use? Automatic, Mirror, Update or Custom? Is there a reason
why you don't use the actual version?

@ Zenju

Can this also happen when we only copy from left to right (Update)? We use
V3.18 at the moment waiting for 3.19 ;)
After this thread my colleague is a little bit afraid that our original files
on the server may be corrupted.

THX in advance.

All the best
Hari

[Zenju]

> my colleague is a little bit afraid that our original files on the server
may be corrupted.
FreeFileSync does NOT roll it's own copy routine, but uses Win-API, even in
v3.16. So concerning possible problems of data corruption I happily pass the
buck to Microsoft or network device drivers.

[hari76]

Hi,

but in my understanding the Update mode (only left to right) leaves the
original files untouched. When I copy one or more files manually in a windows
environment, locally or over network and the process fails the source file is
still valid, only the destination file is corrupted. Only if you sync back the
corrupted one then the original should be corrupted too.
Or is there a mistake in my thoughts?

THX
Hari

[Zenju]

>Only if you sync back the corrupted one then the original should be corrupted
too. Or is there a mistake in my thoughts?
No, thats right. FFS even goes a step further than Windows explorer and
employs "transactional file copy", namely first copies a file under a temp
name, and only after this succeeded, replaces the original file. This avoids
data corruption due to network loss are any other failure in the middle of the
copy process.

[hari76]

Thanks for your quick reply.
For me this sounds good, I guess this will also reassure my colleague.

Greetings
Hari

[normahs]

@Hari

I am not sure which mode i used since i only used this program once and had it
corrupt 1-1.5TB of movies, series and personal data. Rar-files can't be
extraced, movie files gives the error "error rendering video" and well.. that
sort of stuff.

I would of course gladly tell you exactly what i did if i remembered, but all
i can recall is that what i wanted to use the program for, was to move what
was not on one side to the other.

If you guys vouch for this program, then i might reinstall it and try it on
two folders i make only for test purposes, but i really don't trust it.
Although i am fully avare of the fact that if you use something the wrong way
once, you will become prejudice to it forever after, i try to stay neutral-
minded.

I've later deletet all the corrupted files and found other ways to move around
it. :-P

It's taken me some time to get back to this post, i am sorry if i appear
nonchalant of it, that's not my meaning. I've just not had time lately. :-)

[Zenju]

@normahs: I understand your scepticism. I also wouldn't trust any program I
have had bad experience is, no matter what exactly went wrong. Usually the
facts are few 1. something went wrong. 2. I used program X., 3. in other cases
everthing went smooth. Natural assumption: Program X did something wrong.

Being the developer and naturally having the best insight into this program I
am able to add some hard facts, to allow more rationale evaluations:

1. FFS uses Windows low-level routine CopyFileEx to transfer files. This is the same routine used in Windows Explorer and probably most other Microsoft products. Going something wrong in this routine is highly unlikely, as it has been tested by millions of users over more than a decade since Windows 2000.

2. The only possiblity to corrupt a file thous is if CopyFileEx is interrupted in the middle of the process. (e.g. network drop, power loss, etc.) FFS avoids this problem by copying the full file to a temp file first. Only if this operation succeeded, the target file is replaced by the temp file. This step is transactional and only renames file names. The file content is not touched.

3. The worst error that FFS could theoretically cause by improper implementation (e.g. errors in source code) is messed up file attributes. (security permissions, and file attributes, file times).

This doesn't mean data corruption cannot happen, but only that it cannot be
caused by the internals of FFS. That's the good thing of relying on well
tested standard routines for the most mission critical task of this tool.

[hari76]

Hi normahs!

First of all, thank you for your reply and don't worry about the time you
needed. This is not a chat, I'm happy to get an answer at all.

Second, I'm truly sorry for you and your bad experience with FFS. I can
imagine what shock it was to see all files corrupted. I have also about 5 Gigs
of Videos, Music, Photos and other personal stuff on my NAS and I guess I'll
become suicidal if this happens to me.
I can't tell you how good and save FFS is like Zenju or other experienced
users because we just use FFS since one week.
What I can tell you is that in this time nothing unusual happens or in other
words the program did what we expect. (knock on wood)
We had a long evaluation period where we test a lot of programs out there
(also commercial ones) and none of them fits our needs so closely like FFS.
At Home I use AllwaySync to update my NAS with my workstation and honestly now
after working with FFS here in the office I consider if I should replace
AllwaySync at home.

Could you finally rescue your data?

All the best
Hari

[hari76]

Sorry for double post but there is no possibility to edit my post.

Of course I meant 5 TB not GB

Hari

[normahs]

@Zenju

Thanks for taking the time to reply :-)

I am not blaming the program in any way. I tried it once, screw'd up and never
dared try it again. It's probably prejudicm because of the first impression
and the scale of it.

I got a Windows Home Server connected to this computer with a GbLAN. I
frequently use both Killcopy copy/move, Fastcopy copy/move and the regular
Windows copy/move. I also recently started using Microsofts own SyncToy
utility for syncing certain folders back and forth.

I can't recall wether or not i paused the program when i used it, but if that
could harm the files, there should not be a pause function to begin with,
therefore i guess that's not it.

Windows Home Server is also very picky how you save files, but seing as i did
this from my workstation and trough the network, that's not the problem
either.

Since FFS also use some sort of cache or temp function, a temporarily network
downtime shouldn't have corrupted all the files at both sides or?

However as i said, the file dates got screw'd up and the last edited date was
before the created date. All the files dated 12.05.2011 or so was corrupt,
what was strange though, was that the folder they were in, was dated like 2
months later.


Update Right Now


Just created two similar folders, one on my workstation and one on the server.
All i remember, was that i fiddled a lot around with settings and made a
custom copy/move and tried to use it to clean out double copies, that's all.
Tried it now and it worked flawlessly.

As i said, i'm not trying to put the blame on the program or any person, i
just want to know what i have to do to provoke such a behaviour so i know how
to prevent it from happening again.

There COULD have been something wrong with the Windows Home Server
installation that might have confused the servers toombstones or file
references, but what i find weird is how the file dates screw'd up. All the
files with "crazy" dates, were corrupt, the others were fine.

Could update file if newer provoke such a behaviour? Or perhaps "also copy
file privileges" or something?

Oh well, it's not a big deal anymore, i just want to know kinda.. :-D

Ben.-

[Zenju]

>paused the program when i used it, but if that could harm
Pausing is fully supported by the Windows copy routine, so you can expect it
to work reliably.

> temporarily network downtime shouldn't have corrupted all the files at both
sides or?
In this case FFS will leave a garbage file around named <original
filename>.ffs_tmp. Since this has a different name, there is no risk of
confusing it with production data. Further, this temp file will be scheduled
for deletion the next time you start FFS so everthing gets cleaned up
automatically.

> There COULD have been something wrong with the Windows Home Server
installation that might have confused the servers
> Could update file if newer provoke such a behaviour? Or perhaps "also copy
file privileges" or something?
The high-level settings within FFS do not matter with regards to data
consistency. There is only a single place within FFS where data is modified
and this is in the copy routine. Here FFS passes responsibility over to
CopyFileEx. As stated above it is very unlikely that a severe error in this
routine has gone unnoticed. So we have to go one level deeper. Naturally
CopyFileEx relies on the next layer in software architecture which are the
device level drivers. The two important ones in this context are network and
hard disk drivers. Both are usually implemented by the same company that sells
these devices. Since these are not so well tested as generic Windows APIs it
is quite possible they contain bugs. One common bug is insufficient error
checking. Your network may have had some connection issues but the network
drivers did not detect the arrival of bad packages and kept on going. On level
up, CopyFileEx got a "everything is fine" status from the drivers and kept
copying corrupted data. At the highest level FFS finishes synchronization with
success.

[hotpocketdeath]

Hello,

I want to add that I have also had a serious problem with corrupt files. I've
lost several hundred video files because of this.

I know FFS is not the cause because it has happened when I do a simple copy
from my NAS to an external storage device. But more importantly, it has
occurred when I used FFS to backup my files from my NAS to some drives for no
other reason then to back them up.

Several months ago, I upgraded the drives in my NAS and used my backups to
restore the files. Afterwards, I have found many corrupted files and traced
them back to the backups which were created through FFS.

I believe the cause of the problem might have been my old network router. I
recently (about 2 weeks ago) upgraded it to completely new router and I have
not been able to reproduce the corruption with an MD5 comparison program.

Now this brings up a question. Why does FFS not have any kind of verification
system in place? I would expect any program that could be used to back up
files to have some kind of file verification, especially if you rely on
outside software to perform needed functions.

I now consider that to be an extreme flaw with the software and there is no
way I could recommend FFS to anyone without a verification system in place.

[Zenju]

>Why does FFS not have any kind of verification system in place?
There is in fact some verification, but it is opt-in via a setting in
globalsettings.xml. But there are three reasons this is not the default:

1. FFS provides the same consistency guarantee as a regular file copy operation via explorer. It doesn't make much sense to be more strict than the tools that are used at other places. When it comes to ensuring consistent data, the whole process is only as strong as its weakest link. And this link are manual file copy operations.

2. Just doing a verfication of copied data is not enough. The files may already have been corrupted before.

3. It is not possible to accurately check whether a copy operation was successful as the hardware which is used handles buffering internally.

So if one is paranoid (in the good way) about the possibility of copy errors,
a file copy tool is not the right level to address this problem. Additional
protection needs to be installed the form of file checksums, e.g. in the
simplest case by using a packer which stores a CRC32 next to each file. In
this case a correct data transmission can be guaranteed. However note that
this does NOT protect against failures that did exist at the time the checksum
was built!

Granted this feature certainly has some "marketing value" by giving users a
false sense of security, as commonly seen in other tools. The same goes for
MD5 or SHA checksums some tools use instead of the faster simple bit-by bit
comparison. FFS is not designed to give false illusions about what is
possible. There has to be some "real" value to each feature, even if this
approach costs a few users which are seduced by shiny names and promises.
Being a non-profit open source it is not hard to make this cut.

[hotpocketdeath]

> 1. FFS provides the same consistency guarantee as a regular file copy
operation via explorer. It doesn't make much sense to be more strict than the
tools that are used at other places. When it comes to ensuring consistent
data, the whole process is only as strong as its weakest link. And this link
are manual file copy operations.

But as has been shown, those tools may not be 100% effective all the time, so
when they fail, FFS fails. Which is exactly what has happened in my situation.
If FFS has the ability to verify a file was successfully copied, why is it not
made easily available instead of hidden in config file. It seems odd there is
not a toggle built into the GUI when the function is built into the program.
Give the users the choice if they want to use it or not.

> 2. Just doing a verfication of copied data is not enough. The files may
already have been corrupted before.

Not the case in this situation. I have verified some files were corrupted
"after" the copying process and the originals were not.

For example, I took a movie to my brothers for us to watch. While there, the
movie failed to play after a certain point. I checked the video and found it
was corrupt. I then went back to the original kept on my NAS and did the same
check and it was perfectly clean.

As I said though, I believe my old router might have been at fault on this. It
had been showing other signs of failure which is why I replaced it. And I have
not been able to reproduce the error since.

> 3. It is not possible to accurately check whether a copy operation was
successful as the hardware which is used handles buffering internally.

All that has to be done is check the MD5 or SHA hash of the original with that
of the copied file after the operation is complete. If it doesn't match, you
know there is something wrong. And many backup programs implement ways of
verifying data integrity, so don't say it isn't possible, because it is.


Frankly, I am rather offended you would accuse this feature as giving a false
sense of security. There is a very real risk of data not being copied
successfully as I have pointed out. If this function had been made available
and known, I could have used it and there's a good chance you wouldn't be here
trying to make it out to be a pointless feature.

Now I have not accused FFS of causing the problem, however, it seems FFS had
the ability to prevent the loss of this data if the function to verify had
been made available. But instead of acknowledging the real world risk, you
seem to dismiss it. I'm not asking you to fix the source of the corruption,
only have a way to verify that the data being copied succeeded.

[Zenju]

> If FFS has the ability to verify a file was successfully copied, why is it
not made easily available instead of hidden in config file.
This is exactly the point, FFS (and other tools) does not have this feature.
Sure it may be possible that a naive re-read of data discovers a file copy
error. But in general this simple approach is not the tool to guarantee the
absence of these errors. Therefore FFS does not advertize it as such.

> And many backup programs implement ways of verifying data integrity, so
don't say it isn't possible, because it is.
Often people give different things the same name and all it creates is
confusion. It's a question how you name this feature. "Prevent file copy data
corruption" is certainly a little fraud but commonly seen. A more fitting name
is "Prevent file copy data corruption... maybe". But this isn't something that
looks good on GUI, and nothing a users would want to click on as the promised
functionality doesn't sound like it's worth it.