> > > As Liviu pointed out above
> > > (http://www.ztw3.com/forum/forum_entry.php?id=121665), the
> verification
> > > switches built into the copy and xcopy commands don't necessarily
> work
> > > because they could be comparing file caches, not the actual
> contents of
> > > the disk.
> > >
> > > With the amount of memory available these days, and with caches
> built
> > > into drives, what do you have to do to be sure you're really
> verifying?
> > > Reboot and compare?
> >
> > That was my original thought too, but certainly in the case of
> Syncback
> > Pro and a Qnap NAS I was getting some verification errors which led
> to me
> > finding some SATA bus errors, which the NAS had in its logs but
> didn't
> > feel the need to communicate to me...
>
> So, the crux of the problem is verifying beyond the 'cache,' correct?
>
> If the verify fails on your NAS when using Explorer (or other
> non-console file manager), does the NAS verify failure get reported back
> to the program making copy request (Explorer, Syncback Pro, or Qnap)?
>
> My guess is that Syncback Pro or Qnap are initiating a File Compare
> independently of the copy process, Correct?

Yes, and I'd like that option for ZTreeeWin for copying important stuff

>
> If that is not correct, consider using ZTree CLP /APIT instead of using
> ZTreeWin's native copy process. (Or if using /APIT, use ZTreeWin's
> native copy process.)

I always use that, partly as I came up with the idea originally :-)
http://www.ztw3.com/forum/forum_entry.php?id=119982

>
> If switching the use of /APIT (use, non-use) does not change things,
> ZTreeWin's Alt-Compare would be the only practical solution.
>
> Alternatively, check your NAS provider for a firmware update to
> accommodate the SATA drives you have. Ultimately, that may be the best
> solution -- Eliminate the failure in the first place.

Yes and no, there will always be problems and it's nice to know when they happen.

>
> Hope this is helpful.
> Ron Metzger