HUGE bug in 1.06.15

Obviously, I said that because that only reason I am not newbie (no hacker) I work on linux and windows environment (servers, too). 

I had to fixing it doing a fk rollback, so works agains with too old firmware 1.04.  

i am having the same issue on both a wdlive and a wd live plus

ntfs drives

no issue with mkv before the upgrade once i went to 1.06 everytime i pugin the external usb drive all mkv files are set to a zero file size

this is occuring on 2 different wd units and 2 different externals (1 seagate and 1 hitachi)

i properly eject the drives before powering off

file system is fine as per check in windows

There is a bug!! in 1.06

any suggestions from the wd team?

i have also tried resetting both boxes but when plug the drives in the files get over written

i can play the mkv files initially but it seems like as part of the scan of the files on the drive it over writes the mkv files to a zero file size

I thing it is better doing a firmaware’s downgrade. It is safe. I did it.

1.06.15 has a new NTFS driver compiled this summer.  The chkntfs tool, however, is still dated from 2010.  Makes me wonder if they remembered to recompile and include the new version with the firmware…

any comments from the wd team??

is this going to be addressed?

wd team

please provide update

I’m sure that they’re working on something.  No ETA’s though.

Some clarity about how file systems work…

When writing files to a drive and choosing to remove the drive without first unmounting it ( ie ‘safely remove drive’ ), yes, you risk corrupting or completely losing the file you were trying to write and possibly now leaving an invalid entry in the file system, be it a FAT, journal, or whatever. Note that in most file systems and in standard operations, this act does NOT risk the other files on the drive, but under certain conditions ( where segments are reallocated on the fly to avoid fragmentation ) in less common file systems, it may be possible. For FAT / FAT32 file system, the only data you stand to lose is whatever data may be present in the disc cache ( if enabled ).

Now in regards to the WD TV Live… in most cases, a FAT32  is used on the various USB drives and in standard embedded linux kernels ( which is basically what the WDTV Live is running ), there is no *cough* ‘smart’ on the fly defragmention that goes on in the background on this type of file system. So while the WD TV Live may write a cache file or what have you on the drive and abruptly removing that drive may not flush the drives physical cache ( if the kernel even enables the drive’s cache, which is may not - see unchecking the write cache option in Windows ), there should be no risk to any other files on the drive.

So if you are using a FAT32 formatted drive and seeing movie files being truncated to 0 bytes, that’s not from abruptly removing the drive, but rather something else behaving very, very badly.

You explain does not work for my case, because my external HDD is formatted NTFS. 

Sounds bad.

this is ntfs on a freshly paritioned defragmented drive

something is wrong with the way wdtv live handles ntfs and mkv files or files over a certain size 4gb +?

In my humble opnion WD is the guilty because I have ubuntu and windows they who reading ntfs without problems 

juggy wrote:

 

something is wrong with the way wdtv live handles ntfs and mkv files or files over a certain size 4gb +?

Not that I’ve ever seen…  Almost all of my files are over 4GB, some close to 40.

NTFS is just fine - your data loss is not due to a failure to unmount.

Same problem for me. When I updated to 1.06.15, I started to notice that some files where becoming 0 bytes.

No matter the file size (>4gb or even very small like subtitles).

Each time I plugged the drive on my Windows 7 machine, Windows had to do a chkdsk.

So far, I downgraded to 1.05.04 and check daily for a new firmware.

I use a WD 2Tb Ntfs formatted harddrive.

Could we know it this bug is open at WD level ?

RoofingGuy wrote:

The file isn’t “written” to, but the file handles that are opened in order to read the file still need to be properly closed.

 

That’s why even if you try to “Safely Remove” a USB drive from Windows, it can’t do it if files are still open (even for reads).  All the handles have to be properly released.

 

Just turning off the power strip, without letting the WDTV close things properly, is kinda bound to cause all kinds of corrupt files and assorted errors.

 

 

It’s not so much that file system errors were never being generated before… it’s just that previous firmwares didn’t scan the file system’s integrity when first booted.

if that is the case under linux, then linux **bleep**. Opening a file for reading should IN NO WAY corrupt the file, even if just turn of the drive (and it won’t under windows). Sure you’d leave file locks hanging in memory unless you rebooted or shut down and restarted.

But write corruptions, nope.

whattheheck wrote:

if that is the case under linux, then linux **bleep**. Opening a file for reading should IN NO WAY corrupt the file, even if just turn of the drive (and it won’t under windows). Sure you’d leave file locks hanging in memory unless you rebooted or shut down and restarted.

But write corruptions, nope.

Sorry, but that is wrong.

Windows and Linux BOTH *write* to the file table EVERY time a file is opened for reading.   Both in NTFS (Windows) and all forms of *nix OS’s, which include Mac OS as well.   

The O/S updates the “ATIME,” or the time/date of last ACCESS.     You open a file for reading, the ATIME gets updated.

If a file is UPDATED, the MTIME record is updated as well.

Windows and Linux and Macs also have a record called “CTIME,” but that is interpreted in different ways depending on the O/S.

Windows uses that time stamp as CREATION time.   Linux / Mac uses that timestamp to record certain types CHANGES to the file record itself (as opposed to the file CONTENTS.)

… so if the modification of the records requires a sector to be relocated (which can happen if the BTREE is being pruned) then those writes can be corrupted, and the BTREE is now corrupt and must be reconstructed.

1 Like

I have downgraded to 1.05.04 one month ago and no files have been deleted/corrupted in that time span. I never had any problems with files becoming zero bytes in earlier firmwares either.

Something was definitely changed in the latest firmware that causes files to become corrupted!

Enforcer wrote:

Same problem for me. When I updated to 1.06.15, I started to notice that some files where becoming 0 bytes.

No matter the file size (>4gb or even very small like subtitles).

Each time I plugged the drive on my Windows 7 machine, Windows had to do a chkdsk.

 

I use a WD 2Tb Ntfs formatted harddrive.

 

    • *I have this problem. WD Elements Desktop 2 ТB ( WDBAAU0020HBK) + WD TV Live 1.06.15. I checked HDD, it hasn’t bad sectors.

I hadn’t problem with WD Elements Desktop 1 ТB and 1.06.15.