Trocafish

Q: Mavericks corrupts external hard drive

My WD MyBook studio 2TB (fw800) suddenly shows up empty on my desktop after a Mavericks upfrade on my mid 2009 mbp.

 

Disk Drill is now scanning the WD, and the files are there, about 1,4 TB of it...

 

How do I get the disc structure back?

 

I have no Mountain Lion OS-mac to test the WD in..

 

I had a bootable Mountain Lion on the WD, could that be the problem?

 

In Disk Drill MyBook has four units; EFI(200Mb), MyBook(1,8Tb), Unallocated 128Mb and Lost partition (200Mb)

iOS 7, Ipad mini + ios7

Posted on Oct 24, 2013 1:08 AM

Close

Q: Mavericks corrupts external hard drive

  • All replies
  • Helpful answers

first Previous Page 46 of 99 last Next
  • by PlotinusVeritas,

    PlotinusVeritas PlotinusVeritas Nov 26, 2013 4:51 PM in response to R C-R
    Level 6 (14,806 points)
    Nov 26, 2013 4:51 PM in response to R C-R

    Do you have a link to this report? ... this blogger didn't seem to know what he was talking about well enough to be a technician employed by WD.

     

     

    He didnt work for WD, he was a tech reporter talking about a data transfer he did to a blank HFS+ formatted USB external WD drive (he did not mention presence of WD software or removal of same)

     

    I saved that info a few days ago on my macbook Air, but I didnt save the link.  He however did reformat and recreate the occurrence.

     

     

     

    I am wondering if preen command (-p) is given as a false permission (-y) in fsck

     

    f = force fsck even if clean (preen only)

    n = assume a no response

    p = just fix normal inconsistencies

    q = quick check returns clean, dirty, or failure

    r = rebuild catalog btree

    u = usage

    y = assume a yes response

     

     

    In preen mode (-y response), the conversion is listed and done

    if possible without user interaction.

     

         -y           Assume a yes response to all questions asked by fsck; this

    should be used with great caution as this is a free license

    to continue (editing) after essentially unlimited trouble has been

    encountered.

     

     

    We obviously know what is being promted at -p

    following errors/warnings are currently handled automatically when the -p flag is specified: ~~  etc

     

    What however at -y 

     

    Since it is established that ill-advised to run fsck on a mounted volume, if -p is initialized, what automatic errors ensue (repartition and corruption.....[?])

     


  • by R C-R,

    R C-R R C-R Nov 26, 2013 4:45 PM in response to Basilic
    Level 6 (17,700 points)
    Nov 26, 2013 4:45 PM in response to Basilic

    Basilic wrote:

    I always have a Finder window in front of me when I plug a disk, and here I can tell that I never saw the real name of my volume in Finder, but straight EFI and MyBook, and I could see the WD app running in the top screen menu bar.

     

    That's why I think that instead of the WD sw I'd instead point the WD fw (firmware) from within the disk controller.

    I do not understand why you concluded that the WD firmware was the source of the problem. From what you say, a WD app was running at the time, which it seems to me points to that as the culprit.

  • by Drew Reece,

    Drew Reece Drew Reece Nov 26, 2013 4:53 PM in response to PlotinusVeritas
    Level 5 (7,798 points)
    Notebooks
    Nov 26, 2013 4:53 PM in response to PlotinusVeritas

    Isn't the fsck caused by similar unsafe disconnects or the log messages reported by GetRealBro?

     

    Nov 24 12:06:02 GetRealBros-MacBook-Pro kernel[0]: hfs: Runtime corruption detected on Seagate 3T, fsck will be forced on next mount.

     

    Once a file system is marked damaged it will be fsck'ed next time right?

    It looks to me like OSX is having a tough time replaying the journal then fscking is going horribly wrong?

  • by PlotinusVeritas,

    PlotinusVeritas PlotinusVeritas Nov 26, 2013 5:18 PM in response to Drew Reece
    Level 6 (14,806 points)
    Nov 26, 2013 5:18 PM in response to Drew Reece

    http://support.apple.com/kb/ta22517

    start up your computer in single-user mode and use fsck to repair the issues.

     

    Handling "overlapped extent allocation" errors reported by Disk Utility or fsck

     

    Checking for files--If you use Disk Utility or fsck in Mac OS X 10.4.2 or later to repair overlapped extent allocation issues, the following things happen when you repair an affected volume using one of these utilities:

    • The repair utility attempts to move the data of the existing overlapped file (or files) to a new location on your hard disk. This move may succeed or fail without displaying any alert.
    • If the move succeeds, the file gets updated to use the new data location. (You can move it again if you wish, of course.)
    • If the move doesn't succeed because of a lack of contiguous available space or other reason, the file data is not moved.
    • A new folder is created in the root level of your damaged hard disk named "DamagedFiles," which contains a symbolic link (or symlink, which is like an alias) with the name "fileID filename" for each file involved in the overlapping extents issue. Use the link (or links) to locate any affected files. Depending on the file, you can then determine if is still usable or if necessary, replace it with a backup. If the original file is a preference file, it's best to just delete it and recreate preferences from the associated application. Be sure to check the contents of all files listed in the DamagedFiles folder as well as in the output from Disk Utility or fsck (Sometimes a file is created instead of a symlink; see below for details.)

      Important: The DamagedFiles folder may not always contain symlinks to all the files that were involved in producing the overlapped extents errors. You should write down the text output generated when you run Disk Utility or fsck with the actual symlinks or files in the DamagedFiles folder. You can also try to manually locate any files that were listed in Disk Utility or fsck error messages that don't appear in the DamagedFiles folder.

      Note: Any files in the DamagedFiles folder that have a fileID less than 16 are (or were) system files. Instead of a symlink, a plain text file gets created for these. Also, if an affected file's name has more than 255 characters, or the path to the file in the file system is greater than 1024 bytes, a plain text file gets created instead of a symlink—you can locate the original file manually to see if it's still usable. If the original file is a preference file, it's best to just delete it and recreate preferences from the associated application.

     

     

     

     

     

    -y  Assumes a yes response to all questions asked by the fsck command. This flag lets the fsck command take any action it considers necessary. Use this flag only on severely damaged file systems.

     

    If you do not have write permission for an affected file system, the fsck command defaults to a no response in spite of your actual response.

     

    (however in most all cases, write permissions ARE present, which means that fsck can do as it 'wishes' [ see -y])

     

    fsck command checks for the following inconsistencies:

    • Blocks or fragments allocated to multiple files.
    • i-nodes containing block or fragment numbers that overlap.
    • i-nodes containing block or fragment numbers out of range.
    • Discrepancies between the number of directory references to a file and the link count of the file.
    • Illegally allocated blocks or fragments.
    • i-nodes containing block or fragment numbers that are marked free in the disk map.
    • i-nodes containing corrupt block or fragment numbers.
    • A fragment that is not the last disk address in an i-node. This check does not apply to compressed file systems.
    • Files larger than 32KB containing a fragment. This check does not apply to compressed file systems.
    • Size checks:
    • Incorrect number of blocks.

     

    I cannot fathom (correct me if wrong), a plausible other source or nexus for cross-HD repartitioning and corruption at this point.

     

    (all still a working theory)

  • by PlotinusVeritas,

    PlotinusVeritas PlotinusVeritas Nov 26, 2013 6:32 PM in response to GetRealBro
    Level 6 (14,806 points)
    Nov 26, 2013 6:32 PM in response to GetRealBro

    /dev/rdisk1s3: fsck_hfs started at Tue Nov 26 08:12:11 2013

    /dev/rdisk1s3: fsck_hfs completed at Tue Nov 26 08:20:08 2013

     

     

    DESCRIPTION

    The fsck_hfs utility verifies and repairs standard HFS and HFS+ file systems.      

     

    The first form of fsck_hfs quickly checks the specified file systems to      determine whether they were cleanly unmounted.      

     

    The second form of fsck_hfs preens the specified file systems.  It is normally started by fsck(8) during systen boot, when a HFS file system is detected.  When preening file systems, fsck_hfs will fix common inconsistencies for file systems that were not unmounted cleanly.  If more serious problems are found, fsck_hfs does not try to fix them, indicates that it was not successful, and exits.      

     

    The third form of fsck_hfs checks the specified file systems and tries to repair all detected inconsistencies.

     

    If no options are specified fsck.hfs will always check and attempt to "fix" the specified file systems.

     

    -r  Rebuild the catalog file on the specified file system.This option currently will only work if there is enough

                       contiguous space on the specified file system for a new catalog file and if there is no damage to the leaf nodes in the existing catalog file.

     

    -R flags Rebuilds the requested btree.  The following flags are supported:

    a Attribute btree
    c Catalog btree
    e Extents overflow btree
    Rebuilding a btree will only work if there is enough free space on the file system for the new btree file, and if fsck_hfs is able to traverse each of the nodes in the requested btree successfully.  Rebuilding btrees is not supported on HFS Standard volumes.

     

    https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/ man8/fsck_hfs.8.html

     

     

    (all below from differerent sources)

     

    NEVER run an fsck on a mounted file system!!! You will almost certainly regret what happens to it

     

    Running fsck on a mounted filesystem can usually result in disk / data corruption

     

    It's well-known that you should never fsck a mounted partition. I can understand how this could easily lead to corruption if the filesystem is written to by fsck

     

    When running the fsck command, you should always unmount the filesystem first. This will reduce the chances of any corruption occurring.

     

    Also take care not to fsck a mounted file system, even root, as you may do more damage to the file system than you intended to correct. Fsck'ing a clean file system does nothing for you other than give you peace of mind. Usually inconsistencies are created when the system is not properly shutdown, such as a power failure or reset. The OS X man pages on fsck are unclear as to whether fsck supports hfs+ file systems.

  • by GetRealBro,

    GetRealBro GetRealBro Nov 26, 2013 7:16 PM in response to PlotinusVeritas
    Level 1 (21 points)
    Nov 26, 2013 7:16 PM in response to PlotinusVeritas

    PlotinusVeritas wrote:

     

    /dev/rdisk1s3: fsck_hfs started at Tue Nov 26 08:12:11 2013

    /dev/rdisk1s3: fsck_hfs completed at Tue Nov 26 08:20:08 2013

     

    ...

    NEVER run an fsck on a mounted file system!!! You will almost certainly regret what happens to it

     

    Running fsck on a mounted filesystem can usually result in disk / data corruption

     

    It's well-known that you should never fsck a mounted partition. I can understand how this could easily lead to corruption if the filesystem is written to by fsck

     

    When running the fsck command, you should always unmount the filesystem first. This will reduce the chances of any corruption occurring.

     

    Also take care not to fsck a mounted file system, even root, as you may do more damage to the file system than you intended to correct. Fsck'ing a clean file system does nothing for you other than give you peace of mind. Usually inconsistencies are created when the system is not properly shutdown, such as a power failure or reset. The OS X man pages on fsck are unclear as to whether fsck supports hfs+ file systems.

    Just to be clear, while fsck was running this AM the disk icon for the Seagate 3T was not on the desktop. So it was not actually "mounted" for use in the Finder etc... And when I launched Disk Utility it showed the partition as grayed out, hence not mounted. But Disk Utility did allow me to try to mount that partition and complained that it could not mount the partition.

     

    In this particular case, the main problem was that Disk Utility didn't tell me WHY the partition could not be mounted and that I should wait for fsck to finish checking the partition. Apparently Apple did not think that a forced fsck on mount could take so long that a user would have time to launch Disk Utility before the fsck  had completed. We're talking about 8 minutes. That's a long time to wait for a drive/volume to mount with ZERO feedback to a user that was not monitoring the console with both the system and fsck_hfs log windows open. I wonder how many Mavericks users would unplug the cable to a drive they thought was not mounted WHILE fsck was running? OOPS!

     

    This morning's mount issue was pretty mild compared to others I've had with this drive. I'll continue to try to force one of the more troublesome mounts with the console up.

     

    --- GetRealBro

  • by PlotinusVeritas,

    PlotinusVeritas PlotinusVeritas Nov 26, 2013 7:41 PM in response to GetRealBro
    Level 6 (14,806 points)
    Nov 26, 2013 7:41 PM in response to GetRealBro

    Just to be clear, while fsck was running this AM the disk icon for the Seagate

     

    It would at this juncture seem (theory) that fsck is "fixing" (corrupting) what isnt broken. Single-source or binary-causation would be very helpful to know at this point as well.

     

     

     

    Outside of this occurrence, the HD over 2TB have been problematic to cope with for both Apple and the "other guys".

     

    There have been SW problems on a mounted drive with who-knows-what 1,000,000+ files.

     

    The 4TB drives from an unnamed mfg. are mechanically so unreliable as to be worthy of recall.

     

    HD makers have even resorting to just now shipping Helium-Filled Hard Drives to accommodate the giant 4TB and 6TB drives, since these show great promise on reducing wear,... and improving hard drive life,... using less power,...lets the mfg. cram more platters in the same sized HD....and will reduce friction and heat,..(all data killers in the case of hard drives)

    http://www.technologyreview.com/news/521011/fast-and-spacious-helium-filled-hard -drives-ready-for-liftoff/

     

    [insert joke about them "flying off the shelves"]

  • by R C-R,

    R C-R R C-R Nov 26, 2013 8:27 PM in response to PlotinusVeritas
    Level 6 (17,700 points)
    Nov 26, 2013 8:27 PM in response to PlotinusVeritas

    PlotinusVeritas wrote:

    It would at this juncture seem (theory) that fsck is "fixing" (corrupting) what isnt broken.

    It is still not clear to me exactly why or how you think fsck is involved in this. If a volume is unmounted normally, its file system is marked as clean, meaning the next time it is mounted fsck "preening" will skip it, so in that case, the -y flag doesn't matter.

     

    Only if the f (force) flag is set will fsck check a clean file system, & only in combination with the y flag will it keep trying to repair one with more than minor problems.

     

    But in no case does it cause a drive to be reformatted, so something else has to be causing that. The fact that the reformatted drives -- even non-WD ones -- are reformatted with a partition named "MyBook" points to some defect in the (old?) WD software.

  • by PlotinusVeritas,

    PlotinusVeritas PlotinusVeritas Nov 26, 2013 9:03 PM in response to R C-R
    Level 6 (14,806 points)
    Nov 26, 2013 9:03 PM in response to R C-R

     

    It is still not clear to me exactly why or how you think fsck is involved in this. If a volume is unmounted normally, its file system is marked as clean,

    But in no case does it cause a drive to be reformatted

     

     

    We can both agree nothing "normal" is going on here, so scrub that premise.

     

    I have not, nor have others users forwarded reformatting, rather repartitioning (EFI / Mybook;  and otherwise on Seagate, and some Hitachi indications, but mostly on RAID and MyBook).

     

    fsck interactive repair. Journaling file systems avoid the need to run fsck - OS X Journaling is on by default in OS X

    (which begs the question why fsck is being prompted on OSX Journaled ext. drives)

     

    As mentioned earlier, to the users here,.... reformatting (not forwarded by myself or others) or repartitioning sans-metadata (this thread) is like arguing what is worse, a bad crash off a cliff or a bad crash off a cliff into the water.

     

    *Obviously reports of data recovery are rolling in, most with less than 'very good' success, in areas of 'countless' files.

     

     

    R C-R Texas, USA 

    is unmounted normally, its file system is marked as clean...so in that case (if seen as normal), the -y flag doesn't matter.

     

    I agree to this of course, ....again what have we here that is 'normal'? (not much) 

     

    and if binary-causation is present and the ext. HD is not fschk as normal? (ergo this thread)

     

     

    My question to yourself or another is given that this was reproduced:

    • "an obvious fault in the node structure where fsck was commanded to diagnose the HFS (OSX ext. journl.) journaled file system"

     

    how determinate are you that under this abnormal issue -r or -p is not given command to the ext. HD. ?

     

    f = force fsck even if clean (preen only)

    n = assume a no response

    p = just fix normal inconsistencies

    q = quick check returns clean, dirty, or failure

    r = rebuild catalog btree

    u = usage

    y = assume a yes response

     

    And if so, what safeguard or patch can be put in place other than single user mode (as indicated by other developers) ?

     

    Like others, I ask you R-C-R kindly or anyone for answers....out of the premise of looking for a temp. fix until a full fix is in place, and if causation can be quickly determined, then surely a quick patch can be established immediately after to help others,.. at least from further data loss.

     

    I "know what I dont know (hopefully)",    I wish I were a coder and could dissect the new WD software, but cannot.

     

    Peace to you R-C-R


  • by PlotinusVeritas,

    PlotinusVeritas PlotinusVeritas Nov 26, 2013 9:19 PM in response to R C-R
    Level 6 (14,806 points)
    Nov 26, 2013 9:19 PM in response to R C-R

    R-C-R

     

    The fact that the reformatted drives -- even non-WD ones -- are reformatted with a partition named "MyBook"

     

     

    This is what is puzzling, since there are many non-WD that are corrupted (as reported) that are not partitioned as "MyBook", and users with 100% certainty never having any WD software present.

     

    A few users who even wiped their internal drives, with a new OSX install of Mavericks, and still report data corruption on a non-WD drive (obviously also without WD software present).

     

    Any hints..?

  • by R C-R,

    R C-R R C-R Nov 26, 2013 9:28 PM in response to PlotinusVeritas
    Level 6 (17,700 points)
    Nov 26, 2013 9:28 PM in response to PlotinusVeritas

    PlotinusVeritas wrote:

    I have not, nor have others users forwarded reformatting, rather repartitioning (EFI / Mybook;  and otherwise on Seagate, and some Hitachi indications, but mostly on RAID and MyBook).

    Again, I'm not sure what you mean by this. For instance, I don't understand the distinction you are making between reformatting & repartitioning a drive.

     

    But regardless of that, there are multiple reports of other brands of drives being reformatted with the characteristic EFI/MyBook partitions, & since the "MyBook" volume name does not occur anywhere in OS X as distributed by Apple, it is pretty clear that the WD software is the culprit when that happens.

     

    Corruption of a drive's file system is a different issue from the reformat/repartition one, with different characteristics. If this discussion is to accomplish anything besides increasing confusion, it is important to be as clear as possible about which issue one is talking about & as detailed as possible about the observed characteristics it displays.

  • by PlotinusVeritas,

    PlotinusVeritas PlotinusVeritas Nov 26, 2013 10:03 PM in response to R C-R
    Level 6 (14,806 points)
    Nov 26, 2013 10:03 PM in response to R C-R

    there are multiple reports of other brands of drives being reformatted with the characteristic EFI/MyBook partitions, & since the "MyBook" volume name does not occur anywhere in OS X as distributed by Apple, it is pretty clear that the WD software is the culprit when that happens.

     

     

    That much is established as a given,       however what needs to be addressed, and you have not commented upon, as stated, are those HD (RAID [seagate mostly] and otherwise) which experience total data loss and are not being repartitioned EFI/MyBook

     

    'corruption' is a mere lay nomenclature which covers what the users are reporting,...obviously exact specificity clarifies more quickly source-causation.

     

    Since I have tested personally nearly 20 diff. HD on both a macbook Pro and a Mac Mini running Mavericks with no 'luck'.., to duplicate the issue, being more specific than other users themselves proclaim "corruption" is not possible (from this end).

     

    There are none here that will enjoin any 'hair-splitting' that either a reformat or a repartition,... is not also by connotation also "corruption"  (data recovery success or not).

     

    Im going off what little/ scant specific information is being reported,...same as yourself.

     

    Obviously empirical diagnosis is quickly aided greater speed thru greater specificity. 

     

     

    You didnt answer, -- what is your conclusion, if any, of:

    • "an obvious fault in the node structure where fsck was commanded to diagnose the HFS (OSX ext. journl.) journaled file system"

     

     

    As you didnt comment yet, what is your conclusion if any as stated by diverse developers to wit:

     

    NEVER run an fsck on a mounted file system!!! You will almost certainly regret what happens to it

     

    Running fsck on a mounted filesystem can usually result in disk / data corruption

     

    It's well-known that you should never fsck a mounted partition. I can understand how this could easily lead to corruption if the filesystem is written to by fsck

     

    When running the fsck command, you should always unmount the filesystem first. This will reduce the chances of any corruption occurring.

     

    Also take care not to fsck a mounted file system, even root, as you may do more damage to the file system than you intended to correct. Fsck'ing a clean file system does nothing for you other than give you peace of mind. Usually inconsistencies are created when the system is not properly shutdown, such as a power failure or reset. The OS X man pages on fsck are unclear as to whether fsck supports hfs+ file systems.

     

     

    R C-R Texas, USA 

    Corruption of a drive's file system is a different issue from the reformat/repartition.

     

    I myself am only interested in helping others,   not to split hairs over the connotation or denotation of the term 'corruption',.....however the point is given as stated, that all specifics paint a sharper picture to aid in diagnosis.

     


  • by jockefardig,

    jockefardig jockefardig Nov 26, 2013 11:20 PM in response to Trocafish
    Level 1 (0 points)
    Nov 26, 2013 11:20 PM in response to Trocafish

    WD has released an update to their WD SmartWare for this issue...

     

    "WD SmartWare update highlights:

     

    Mac release 1.3.6 (updated 11/25/2013)

    Fixed an issue related to reports of some customers, under certain conditions, experiencing data loss when updating to Apple's OS X Mavericks (10.9).

    For more information on this issue, please click here.

     

    *Please note that if you have a previous version of WD Drive Manager installed on your computer, this software package will automatically uninstall the old version and install a new version.

     

    View the release notes for complete update information."

     

    More info on it here: http://wdc.com/wdproducts/wdsmartwareupdate/wdsmartware.asp?id=wdfGeneric&os=mac

  • by petermac87,

    petermac87 petermac87 Nov 26, 2013 11:25 PM in response to jockefardig
    Level 5 (7,402 points)
    Nov 26, 2013 11:25 PM in response to jockefardig

    Your link does not point to any 10.9 compatable software. There are other links posted over the last couple of days.

     

    Cheers

     

    Pete

  • by Hellurei,

    Hellurei Hellurei Nov 26, 2013 11:40 PM in response to petermac87
    Level 1 (0 points)
    Nov 26, 2013 11:40 PM in response to petermac87
first Previous Page 46 of 99 last Next