.. I then switched to a Win 7 PC and repeated the same process ... the cksum is different!! 🙂 Seems to be a Win 7 only problem? Possibly related to a Samba upgrade in T6? I think I will go back 4.1.8 and wait for 4.1.9 ..
Wow, thanks for posting your findings. That's very interesting, I wonder if it's some Samba SMB2 bug.
Samba 3.5 also includes experimental support for SMB2.[16] Samba 3.6 fully supports SMB2, except the modification of user quotas using the Windows quota management tools.[17]
Apparently 3.6 is where SMB2 becomes stable. T6 was running 3.5.12 and T2 was running Samba 3.0.
I like that we are running new Samba (for security reasons and also that SMB2 is set to give one hell of a performance increase), so see the solution as Netgear either trying 3.6 Samba or making SMB2 an optional feature in Frontview listing "(reading file information while writing to it may in some instances cause file corruption)".
I might try again, but this time disabling SMB2 on my Windows 7 SP1 x64 computer but am sure it will work.
.. I then switched to a Win 7 PC and repeated the same process ... the cksum is different!! 🙂 Seems to be a Win 7 only problem? Possibly related to a Samba upgrade in T6?
I think I will go back 4.1.8 and wait for 4.1.9 ..
matthew1471, thanks for the great work nailing down how to reproduce this, and the super-handy utility! And sorry everybody for the trouble.
Interestingly, I have never been able to reproduce this issue by downloading straight from Firefox onto a NAS share -- even downloading several large files and making Windows Explorer refresh like a mad-man. But I am able to reproduce it easily with that utility, so there is most definitely a problem here.
So at this point, we don't know exactly what caused the issue, but changing a couple settings for 4.1.9-T9 (which I just posted), I can no longer reproduce the issue. We will continue to dig until we completely track it down, but if you guys could try 4.1.9-T9 and either confirm or deny that it resolves the data corruption issue for you, that would be very helpful.
matthew1471, thanks for the great work nailing down how to reproduce this, and the super-handy utility! And sorry everybody for the trouble.
Interestingly, I have never been able to reproduce this issue by downloading straight from Firefox onto a NAS share -- even downloading several large files and making Windows Explorer refresh like a mad-man. But I am able to reproduce it easily with that utility, so there is most definitely a problem here.
So at this point, we don't know exactly what caused the issue, but changing a couple settings for 4.1.9-T9 (which I just posted), I can no longer reproduce the issue. We will continue to dig until we completely track it down, but if you guys could try 4.1.9-T9 and either confirm or deny that it resolves the data corruption issue for you, that would be very helpful.
still doing it for me with T9 EDIT: Tried it with several different files and all have landed corrupt. The error this time is the file is not complete as before and the message is that the software is not for the version of windows you have blah blah
Gone back to T2 and it's fine again same files down as before and they are perfect. Yes winblows 7 here, I'll try on my fedora box a bit later
Same here with 4.1.9-T6 on a Duo, installed yesterday (just before it was pulled, I suppose) and saw two instances of data corruption from my Win7 PC:
1. Using the Win7 image viewer to view and in some cases rotate pictures. Done that on a folder of about 50 pictures, about one in 10 becomes unreadable.
2. Using QuickShadow Backup (mirroring utility): 23/04/2012 15:44:21: |-> Copy of C:\Users\Thierry\AppData\Roaming\Apple Computer\MobileSync\Backup\d6080810cf24934a841ecf7ecfcbce7e845e8203\3a38f8ca430ae354fea5a466fe823fa5f830179b failed - destination is not writable (off-line or full?), deferring 23/04/2012 16:06:42: |-> Verify FAILED 23/04/2012 17:33:26: |->Rename FAILED of \\nassau\Shadow-Turquois\C\Users\Thierry\AppData\Roaming\Microsoft\Excel\971%20Extension%202010-2%20v6301743740279537248\971%20Extension%202010-2%20v6((Autosaved-301743903559950560)).xls to \\nassau\Shadow-Turquois\C\Users\Thierry\AppData\Roaming\Microsoft\Excel\971%20Extension%202010-2%20v6301743740279537248\971%20Extension%202010-2%20v6((Unsaved-301743903559950560)).xls -> Dest file not there. Expect a copy to follow.
Going back to T2 then, which is so slow as to make the NAS almost unusable, but at least does not corrupt data...
T9 could still hit this issue, but the chance is greatly reduced. It appears to be an issue with the file pointer getting moved (possibly by a read or write of another part of the file mid-transfer), and not properly reset. So the data could get written to the wrong place in the file under some circumstances. I've just posted T10 which should eliminate that possibility.
Well after trying a few files it seems T10 has fixed the issue, good work.
That's great news. Thanks for bringing this up and including all the useful information to help reproduce it. And really, sorry to anyone affected by this.
Yes, much faster, and no data corruption so far... Many thanks for the quick turnaround on data corruption, and fixing the throughput issue was long overdue, but such a relief! My NAS and I are friends again - thank you once more.
