Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[nrf]

wow. this seems like something worth jumping up and down over!
I'm glad mine sits on the shelf until it becomes worthy of its advertised function.


nrf 

[nickOfTime]

With CopyAndVerify writing files and reading files are interleaved (but separate -- write complete and closed before read happens):

copy: write destination file 1
verify: read destination file 1
copy: write destination file 2
verify: read destination file 2
...

If I split it up, so all copies happen first, then all verifies after, there is no corruption.  I have added Copy.java and Verify.java to my web site.

BTW, just to make things perfectly clear... in all tests, source directory is on the PC, destination on the DNS-321.

[nickOfTime]

wow. this seems like something worth jumping up and down over!
I'm glad mine sits on the shelf until it becomes worthy of its advertised function.


nrf 

I've found an acceptable workaround, at least for me.  See posting above.  All I need to do is throw together a robust verifier that recurses through directories.  I'll keep my DNS-321 for now...

[peas]

nickoftime - thanks for reporting your findings and a way to recreate the issue.  I wish it weren't the case, but now that there's a verified simple way to trigger the bug, will Dlink prioritize a fix for it?

I hope the naysayers (fordem) will learn to eat their humble pie and not discount bugs just because they haven't encountered them.  Bugs have a habit of sneaking up on you and defying logic, at least until they are fully understood.

[nickOfTime]

nickoftime - thanks for reporting your findings and a way to recreate the issue.  I wish it weren't the case, but now that there's a verified simple way to trigger the bug, will Dlink prioritize a fix for it?

I hope the naysayers (fordem) will learn to eat their humble pie and not discount bugs just because they haven't encountered them.  Bugs have a habit of sneaking up on you and defying logic, at least until they are fully understood.

I wish it weren't the case either, but it's better to try to verify it than just leaving it hang out there.  How did I find it?  I just wrote a little program that did as the reviewer on Amazon described -- copy then verify.

I don't blame fordem or D-Link employees for their reactions.  Having worked as a software developer for 25 years I've been there plenty of times.  Hopefully over time I've become less reactionary, although you'd have to ask my customers about that.  But generally with software or hardware, where there's smoke, there's fire.  As for the statement from a D-Link employee:

There is NO data corruption in 1.01 firmware for the DNS-321. It has already been tested and verified in lab

That's a strong statement, but impossible to back up.  All you can say is that corruption hasn't been encountered in the tests that were run.  You can't test and verify what you haven't reproduced.

[Fatman]

Thanks for your work writing a real world (and hopefully reproducible) replication procedure (and doubly thanks for providing code so it can be peer reviewed, that is more helpful than some realize [though obviously you do]).

As for the comments you quoted, you are correct his wording was a bit strong, though I think (how could I know, I am not he) that his intention matched what you said, or it was close enough for government work.

[nickOfTime]

Thanks for your work writing a real world (and hopefully reproducible) replication procedure

You're welcome.  I also had a trouble ticket opened (DLK400396514) just so that this gets on-record.

[Fatman]

You're welcome.  I also had a trouble ticket opened (DLK400396514) just so that this gets on-record.

Thanks again for your thoroughness with this issue, though I am going to let you in on a little secret, if you call in it floats to the top quicker.  This isn't due to any particular bias, but it has to do with the number and quality of e-mails we get vs. the fact that if you call in and talk over the tech's head you will end up escalated, that doesn't work as well via e-mail.  It looks like your e-mail received a fairly generic response at first, I apologize.

[nickOfTime]

Thanks again for your thoroughness with this issue, though I am going to let you in on a little secret, if you call in it floats to the top quicker.  This isn't due to any particular bias, but it has to do with the number and quality of e-mails we get vs. the fact that if you call in and talk over the tech's head you will end up escalated, that doesn't work as well via e-mail.  It looks like your e-mail received a fairly generic response at first, I apologize.

No problem with the generic replies, I'm used to it.  I only emailed to get a trouble ticket associated with the issue.  email seems to be best at getting things on-record, not transcribed by whoever took your call.  I find that forums are best at getting attention.

Thanks for getting this sent up to the right place.

[freakyg]

soooo what's the "status of '321 data corruption caused by Linux kernel bug?"?.  The latest firmware for this thing is v1.01 dated 11/11/08 (aside from the 1.02 "Fix for Deskstar").  I think it's a little unreasonable that home or small business owners would have a decent product - as long as you can write (or use) copy/verification software.  Isn't that (or part of) what this does?

[nickOfTime]

soooo what's the "status of '321 data corruption caused by Linux kernel bug?"?.  The latest firmware for this thing is v1.01 dated 11/11/08 (aside from the 1.02 "Fix for Deskstar").  I think it's a little unreasonable that home or small business owners would have a decent product - as long as you can write (or use) copy/verification software.  Isn't that (or part of) what this does?

I haven't heard anything back, but I'm pretty sure they're working on it.  My web server logs shows about 100 hits that (assuming IP records are correct) work out to between 8:30am and 10:30am local time of the client (i.e. the people making requests of the web server) the first work day after I reported this.

I'm not trying to make excuses (and why should I?  I'm a customer, not an employee), but I can say from working in the industry that when a bug report that sounds serious but is pretty vague comes in, you assign somebody a bit of time to look at it and if nothing comes of it is marked as not reproduceable and closed.

I hit this because I verify data.  I doubt many people do.  Just look at async (aka nosync) transaction modes on databases to see how casual even businesses are to data corruption.  It's like no safety net tightrope walking.

[Fatman]

Isn't that (or part of) what this does?

Not to get in nickOfTime's way (he seems to have this on lockdown), but it is also worth noting that bug or no bug this product does not do data verification.  It would be a good idea regardless.  I am not saying we don't have a bug or that we aren't going to fix it, just that if I cared about my data I would be already verifying it.

[youlian]

Does anybody have an idea how likely is data corruption when just copying files from XP to dns-323 using windows explorer ?

I do not use special backup software I just copy files using windows explorer.

[nickOfTime]

Does anybody have an idea how likely is data corruption when just copying files from XP to dns-323 using windows explorer ?

I do not use special backup software I just copy files using windows explorer.

Nobody can guarantee anything, but...

The bug appears to be related to constant switching from reading to writing in a very short time.  When you are only copying files (such as with windows explorer) between your PC and the DNS, then you are either reading (if copying from the DNS) or writing (copying to the DNS), not both.

I have only been able to reproduce the bug on a DNS-321.  I've owned a DNS-323 for almost a year and a half and have never had data corruption.  I am certain of this because I verify files.  After I reproduced the bug on the DNS-321, I tested my DNS-323 for a few days (solid, no breaks) and did not hit the bug.

Despite the obvious similarities between the DNS-321 and DNS-323, the hardware inside is quite different.  Since this appears to be a timing bug, different hardware can have different results.

[peas]

Not to get in nickOfTime's way (he seems to have this on lockdown), but it is also worth noting that bug or no bug this product does not do data verification.  It would be a good idea regardless.  I am not saying we don't have a bug or that we aren't going to fix it, just that if I cared about my data I would be already verifying it.

Yes in general it's best to verify data.  In this specific case the act of verifying data to the DNS-321 causes data corruption, whereas not verifying is unlikely to cause corruption.  The typical procedure is to write and immediately verify that file, as opposed to writing all files then verifying from the beginning (more efficient code-wise not having to store the entire list or reload it).  I understand your sentiment but in this case what you're condoning will directly lead to data corruption.

Does DLink have a release scheduled to fix this?