What is faster: synchronize all of the files / folders and after click compare (by content)?
Or:
Set VerifyCopiedFiles Enabled="true"
and let FFS automatically verify the files after having synchronized all of them?
What is faster: Synchronizing and after click "Compare" (by content) or use Set VerifyCopiedFiles Enabled="true"?
- Posts: 4
- Joined: 9 Mar 2015
-
- Site Admin
- Posts: 7282
- Joined: 9 Dec 2007
VerifyCopiedFiles only compares files that FFS has just copied, while binary comparison will compare all files by default (but it will honor the file exclusion filter).
On the other hand VerifyCopiedFiles suffers from the issue of potentially reading buffered data, which can make it a placebo. Therefore binary comparison if used correctly (by making sure file buffers are empty, e.g. restart the system before) is a better way to check file consistency.
On the other hand VerifyCopiedFiles suffers from the issue of potentially reading buffered data, which can make it a placebo. Therefore binary comparison if used correctly (by making sure file buffers are empty, e.g. restart the system before) is a better way to check file consistency.
- Posts: 4
- Joined: 9 Mar 2015
> VerifyCopiedFiles only compares files that FFS has just copied
So, to those files belong the ones which will be copied when not existing on the other side and newer files? And when comparing by the compare button only the files are checked by content which already exist (same name and extension) on the destination side? Is that correct?
> while binary comparison will compare all files by default (but it will honor the file exclusion filter).
Binary comparison is the one done when clicking the button "Compare" (compared by "File content")?
And "VerifyCopiedFiles Enabled="true"" is another kind of comparison? May be by check sum?
> (but it will honor the file exclusion filter).
So e.g. only the files are compared (by content, if set) which are included in the filter, respectively not excluded and are already existing (same name and extension) on the destination side, right? So if in the include filters is set *.rar FFS then only will compare rar files before synchronizing / copying, is that right?
> On the other hand VerifyCopiedFiles suffers from the issue of potentially reading buffered data, which can make it a placebo
That sounds unbelievable. I hadn't supposed that. But it sounds like that method of comparison would not be useful at all, or am I missing anything? So, if I understand it right, VerifyCopiedFiles Enabled="true" lets FFS possibly / may be check the data / content of a copied file (still) bing in such a buffer / cashe and not the content of the file (completely) written to the drive? And that never does happen, when I use compare by content (so click the left button on top, "compare by content" activated?
> Therefore binary comparison if used correctly (by making sure file buffers are empty, e.g. restart the system before)
The system? Sounds like to restart the Computer / operating system. Or do you mean restart FFS? And restart before comparing? Before opening FFS? If yes, why is that, so, there should not be any file content in such a buffer, because there still was not anything copied?
When I often changes Set VerifyCopiedFiles Enabled="true" to false and vice versa it might be a little circumstantially. Is there a way to change these values easier (than closing FFS, then open the GlobalSettings.xml change the value and re-start FFS)?
I have (had) some transfer problem, do not know what it is caused by. Some / many of the transferred / copied / moved files just are corrupt on some of my or all of my external drives. And I want to save as many files as possible, copy them to other external drives. So, that is why I ask for the verifying / comparing method.
Sorry for my bad understanding.
So, to those files belong the ones which will be copied when not existing on the other side and newer files? And when comparing by the compare button only the files are checked by content which already exist (same name and extension) on the destination side? Is that correct?
> while binary comparison will compare all files by default (but it will honor the file exclusion filter).
Binary comparison is the one done when clicking the button "Compare" (compared by "File content")?
And "VerifyCopiedFiles Enabled="true"" is another kind of comparison? May be by check sum?
> (but it will honor the file exclusion filter).
So e.g. only the files are compared (by content, if set) which are included in the filter, respectively not excluded and are already existing (same name and extension) on the destination side, right? So if in the include filters is set *.rar FFS then only will compare rar files before synchronizing / copying, is that right?
> On the other hand VerifyCopiedFiles suffers from the issue of potentially reading buffered data, which can make it a placebo
That sounds unbelievable. I hadn't supposed that. But it sounds like that method of comparison would not be useful at all, or am I missing anything? So, if I understand it right, VerifyCopiedFiles Enabled="true" lets FFS possibly / may be check the data / content of a copied file (still) bing in such a buffer / cashe and not the content of the file (completely) written to the drive? And that never does happen, when I use compare by content (so click the left button on top, "compare by content" activated?
> Therefore binary comparison if used correctly (by making sure file buffers are empty, e.g. restart the system before)
The system? Sounds like to restart the Computer / operating system. Or do you mean restart FFS? And restart before comparing? Before opening FFS? If yes, why is that, so, there should not be any file content in such a buffer, because there still was not anything copied?
When I often changes Set VerifyCopiedFiles Enabled="true" to false and vice versa it might be a little circumstantially. Is there a way to change these values easier (than closing FFS, then open the GlobalSettings.xml change the value and re-start FFS)?
I have (had) some transfer problem, do not know what it is caused by. Some / many of the transferred / copied / moved files just are corrupt on some of my or all of my external drives. And I want to save as many files as possible, copy them to other external drives. So, that is why I ask for the verifying / comparing method.
Sorry for my bad understanding.
-
- Site Admin
- Posts: 7282
- Joined: 9 Dec 2007
If you want to be sure that a file comparison really accesses the physical disk you have to make sure that it is not buffered. The simplest way to do this is to restart the operating system. Alternatively if you have just plugged in some external drive you know that data is not buffered.
The problem with "VerifyCopiedFiles" is that it is applied directly after file copying, so chances are that it could be reading buffered data. Therefore this function is not that useful and there's no reason to put it into GUI or make it more easily accessible.
Buffering is inherent in modern operating systems, and trying to get around it is probably a useless effort:
http://blogs.msdn.com/b/oldnewthing/archive/2012/09/19/10350645.aspx
The problem with "VerifyCopiedFiles" is that it is applied directly after file copying, so chances are that it could be reading buffered data. Therefore this function is not that useful and there's no reason to put it into GUI or make it more easily accessible.
Buffering is inherent in modern operating systems, and trying to get around it is probably a useless effort:
http://blogs.msdn.com/b/oldnewthing/archive/2012/09/19/10350645.aspx
- Posts: 4
- Joined: 9 Mar 2015
> The simplest way to do this is to restart the operating system.
Hmmm, so restart the computer, close all programs, etc. takes about 20 minutes here until all of the programs are open / accessible again.
> Alternatively if you have just plugged in some external drive you know that data is not buffered.
So, after plugging in an external drive the first comparison of an internal drive with that external one will work, but a second comparison between the internal drive (same files) with another external drive might not work correctly anymore, because the content / files from the first comparison still is / might be in the buffer?
> The problem with "VerifyCopiedFiles" is that it is applied directly after file copying, so chances are that it could be reading buffered data. Therefore this function is not that useful and there's no reason to put it into GUI or make it more easily accessible.
Buffering is inherent in modern operating systems, and trying to get around it is probably a useless effort:
http://blogs.msdn.com/b/oldnewthing/archive/2012/09/19/10350645.aspx
Thank you for the link. So - if I understand it correctly - that appears to mean, one should not use it at all, this function is completely senseless (or what for could one use it?). But why is it available at all?
Does that also refer to checking files by check sum (I guess, it does, else FFS would have that option)? So could I easily check the files by check sum without having to empty the buffer?
Sorry for asking, yes, same problem:
> The readChecksum and writeChecksum are identical because they operate on the same bytes. (In fact, the compiler might even optimize the code by merging the calculations together.) The only way something could go awry is if you have flaky memory chips that change memory values spontaneously.
Have I understood that correctly:
> VerifyCopiedFiles only compares files that FFS has just copied
So, to those files belong the ones which will be copied when not existing on the other side and newer files? And when comparing by the compare button only the files are checked by content which already exist (same name and extension) on the destination side? Is that correct?
> while binary comparison will compare all files by default (but it will honor the file exclusion filter).
Binary comparison is the one done when clicking the button "Compare" (compared by "File content")?
And "VerifyCopiedFiles Enabled="true"" is another kind of comparison? May be by check sum?
> (but it will honor the file exclusion filter).
So e.g. only the files are compared (by content, if set) which are included in the filter, respectively not excluded and are already existing (same name and extension) on the destination side, right? So if in the include filters is set *.rar FFS then only will compare rar files before synchronizing / copying, is that right?
How big is such a buffer, how much data can it take? I could imagine, when I copy all files (may be 20.000 to 30.000) form a full 4 TB drive, the buffer only would be filled with some of the files.
Hmmm, so restart the computer, close all programs, etc. takes about 20 minutes here until all of the programs are open / accessible again.
> Alternatively if you have just plugged in some external drive you know that data is not buffered.
So, after plugging in an external drive the first comparison of an internal drive with that external one will work, but a second comparison between the internal drive (same files) with another external drive might not work correctly anymore, because the content / files from the first comparison still is / might be in the buffer?
> The problem with "VerifyCopiedFiles" is that it is applied directly after file copying, so chances are that it could be reading buffered data. Therefore this function is not that useful and there's no reason to put it into GUI or make it more easily accessible.
Buffering is inherent in modern operating systems, and trying to get around it is probably a useless effort:
http://blogs.msdn.com/b/oldnewthing/archive/2012/09/19/10350645.aspx
Thank you for the link. So - if I understand it correctly - that appears to mean, one should not use it at all, this function is completely senseless (or what for could one use it?). But why is it available at all?
Does that also refer to checking files by check sum (I guess, it does, else FFS would have that option)? So could I easily check the files by check sum without having to empty the buffer?
Sorry for asking, yes, same problem:
> The readChecksum and writeChecksum are identical because they operate on the same bytes. (In fact, the compiler might even optimize the code by merging the calculations together.) The only way something could go awry is if you have flaky memory chips that change memory values spontaneously.
Have I understood that correctly:
> VerifyCopiedFiles only compares files that FFS has just copied
So, to those files belong the ones which will be copied when not existing on the other side and newer files? And when comparing by the compare button only the files are checked by content which already exist (same name and extension) on the destination side? Is that correct?
> while binary comparison will compare all files by default (but it will honor the file exclusion filter).
Binary comparison is the one done when clicking the button "Compare" (compared by "File content")?
And "VerifyCopiedFiles Enabled="true"" is another kind of comparison? May be by check sum?
> (but it will honor the file exclusion filter).
So e.g. only the files are compared (by content, if set) which are included in the filter, respectively not excluded and are already existing (same name and extension) on the destination side, right? So if in the include filters is set *.rar FFS then only will compare rar files before synchronizing / copying, is that right?
How big is such a buffer, how much data can it take? I could imagine, when I copy all files (may be 20.000 to 30.000) form a full 4 TB drive, the buffer only would be filled with some of the files.
