(Using Windows 7 64bit, writing to a Lacie Network Space 2 NAS drive reached
via \\ notation.)
I use the Mirror operation to take backups of my files, but today I noticed
that it was asking to overwrite files that hadn't changed. Further examination
showed that the files on the destination drive were bigger, but I knew I
hadn't changed them myself.
Using 5.3, my files were written to the remote disk in a slightly corrupted
form - specifically, the file sizes (for at least some files, not all, it
seems) were rounded up, usually to the nearest 512 bytes I think, with the end
of the file padded out by zeros.
I tried again with 5.4, which obviously overwrites all those files again
(seeing the size discrepancy). This time most of the files seemed to get
written ok, but a few were still being rounded up and padded. A second
synchronisation attempt seemed to catch them and fix them.
This is unfortunate because now I have to run another Compare after every
Mirror to be sure that the files were not corrupted in transfer.
Is this likely to be due to the new unbuffered copy operation, and maybe the
NAS driver? Or maybe something else?
Files copied with extra bytes appended
- Posts: 5
- Joined: 28 Apr 2001
- Site Admin
- Posts: 7279
- Joined: 9 Dec 2007
Yes, this is a bug in the NAS driver. FFS 5.3 implemented a new "officially
documented Windows option" offered since Windows Vista to prevent file copy
operations to clear/overwrite the system cache with useless data, thous
slowing down the system. Unfortunately this triggers bugs in file system
implementations that were never tested under this condition.
So I had to remove it again in 5.4 and cater for the "lowest common
denominator".
[404, Invalid URL: https://sourceforge.net/tracker/?func=detail&aid=3529683&group_id=234430&atid=1093080]
documented Windows option" offered since Windows Vista to prevent file copy
operations to clear/overwrite the system cache with useless data, thous
slowing down the system. Unfortunately this triggers bugs in file system
implementations that were never tested under this condition.
So I had to remove it again in 5.4 and cater for the "lowest common
denominator".
[404, Invalid URL: https://sourceforge.net/tracker/?func=detail&aid=3529683&group_id=234430&atid=1093080]
- Posts: 5
- Joined: 28 Apr 2001
Thank you for your quick reply. I thought I saw a few small files that didn't
get written properly the first time with 5.4, but I could have been mistaken.
I'll report back if I see anything in future.
get written properly the first time with 5.4, but I could have been mistaken.
I'll report back if I see anything in future.