Reply
Occasional Advisor
juggy
Posts: 8
Registered: ‎03-02-2010
0

Re: HUGE bug in 1.06.15

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 +?

Occasional Advisor
Michelo
Posts: 7
Registered: ‎08-30-2011
0

Re: HUGE bug in 1.06.15

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

Honored Contributor
TonyPh12345
Posts: 17,808
Registered: ‎01-11-2010
0

Re: HUGE bug in 1.06.15


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.

 

===Live SMP / Live Hub x2 / Live+ / Live x2 / 24 TBytes of QNAP + WD NAS ===
Advisor
jlaborde3
Posts: 19
Registered: ‎06-24-2010
0

Re: HUGE bug in 1.06.15

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

Occasional Visitor
Enforcer
Posts: 1
Registered: ‎11-17-2011
0

Re: HUGE bug in 1.06.15

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 ?

Honored Contributor
whattheheck
Posts: 566
Registered: ‎12-01-2009
0

Re: HUGE bug in 1.06.15


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.

--
WDTV Live needs: Better in-file navigation. Arrow keys to skip back and forth 10/30 secs in AVIs/MKVs/Mp4s/Mp3s.
Honored Contributor
TonyPh12345
Posts: 17,808
Registered: ‎01-11-2010

Re: HUGE bug in 1.06.15

[ Edited ]

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.

 

 

===Live SMP / Live Hub x2 / Live+ / Live x2 / 24 TBytes of QNAP + WD NAS ===
Advisor
Pacman2011
Posts: 15
Registered: ‎05-14-2011
0

Re: HUGE bug in 1.06.15

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!

 

 

Member
Amper
Posts: 2
Registered: ‎03-27-2011
0

Re: HUGE bug in 1.06.15

[ Edited ]

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.
Occasional Advisor
juggy
Posts: 8
Registered: ‎03-02-2010
0

Re: HUGE bug in 1.06.15

wd team

 

this is a critical bug which destroys files

ca n we please get an update on it

Forums | Ideas | News and Announcements | Register | Sign in | Help | Forum Guidelines
Copyright © 2001 - 2010 Western Digital Corporation, All rights reserved. | Trademarks | Privacy | Terms of Service | Terms of Use | Copyright | Contact WD