Shareef Yousef 

I have two Seagate drives that have been failing to mount and no WD or Seagate software installed.

How certain are you that you did not use the packaged software that Seagate included? Namely:

Backup Plus and GoFlex Desk

http://www.seagate.com/support/external-hard-drives/desktop-hard-drives/goflex-d esk/goflex-desk-thunderbolt-master-dl/

-- Or Seagate "DiscWizard"

Seagate, like WD, has an infamous premise of including "helpful" software on all its drives (by helpful, I imply useless)

R C-R Texas, USA 

Note that it does not actually erase file data or any metadata stored as a part of that data, but once the old directory & associated info is erased the system has no way of knowing where that data is, how to access it, or protect it from being overwritten with new data.

Too true friend,... however there is a bit less than 1 degree of separation between your above and genuine data erasure (which when purposefully erased is still present until the sector(s) is overwritten)

In the case of countless 100s of 1000s of files with complex metadata, best effort recovery has proven only often partially successful and incredibly intense,...as per repartitioning [EFI, MyBook].

In the case of non RAID Hitachi, Toshiba, Seagate USB (not prone to unmounting) which have both been repartitioned and not within a 100 miles of any WD firmware or HD controller software, WD is not causative;...

nor is any mechanical HD at fault in and of itself, be it WD, Seagate, Toshiba, or Hitachi (as I know you know)

Despite Shareef Yousef issue of unmounting, most Seagate mentions here and elsewhere involve the likewise prone WD-effect of repartitioning and loss of file and metadata corruption.

*Again, a coder here need to dismantle the WD "fix" (for further corruption/repartitioning) and contrast it against former iterations of their control software.

WD specifically has recently stated: - "A specific set of conditions and timing sequences between the OS and the WD software utilities has to occur to cause this issue."

R C-R Texas, USA 

WD Drive Utilities for Mac. According to WD this has five functions:

Run drive diagnostics

Of these, running drive diagnostics (checking S.M.A.R.T. status) might be useful

Since that is the highest common denominator APP in use on these WD RAID and externals, I'm inclined to presume the source lies within same, rather than be 'useful' based upon:

Recent reports from a computer technician of WD reproduced repartitioning involves - "an obvious fault in the node structure where fsck was commanded to diagnose the HFS (OSX ext. journl.) journaled file system" on the WD drive @ corruption.

The very same node structure where the cataloging system that keeps track of where everything was, was then kaput.

If someone could test same: there may be help by the use Single User Mode and fsck to repair a disk after a repartitioning

http://osxdaily.com/2013/08/07/how-to-repair-a-mac-disk-with-fsck-from-single-us er-mode/

Basilic wrote:

The $1M question, which process got enough privileges granted to repartition the ext. disk. Why OSX would have done that?

If the above reproduced effect is valid and complete (I am sure as he reported it is valid, if not complete) then EITHER Mac OSX is commanding or WD software is commanding the external HD @ which repartitioning is occurring (what the combination is, who is yet to know)

Mac OS X version 10.9

fsck -- filesystem consistency check and interactive repair

DESCRIPTION
     The first form of fsck preens a standard set of filesystems or the specified filesystems.  It is normally used in the script /etc/rc during automatic reboot.  Here fsck reads the filesystem descriptor
     table (using getfsent(3)) to determine which filesystems to check.  Only partitions that have ``rw,''
     ``rq'' or ``ro'' as options, and that have non-zero pass number are checked.  Filesystems with pass
     number 1 (normally just the root filesystem) are checked one at a time.  When pass 1 completes, all
     remaining filesystems are checked, running one process per disk drive.  The disk drive containing each
     filesystem is inferred from the shortest prefix of the device name that ends in one or more digits; the
     remaining characters are assumed to be the partition designator.  In preening mode, filesystems that
     are marked clean are skipped.  Filesystems are marked clean when they are unmounted, when they have
     been mounted read-only, or when fsck runs on them successfully.

     It should be noted that fsck is now essentially a wrapper that invokes other fsck_XXX utilities as
     needed.  Currently, fsck can invoke fsck_hfs, fsck_msdos, fsck_exfat, and fsck_udf.  If this underlying
     process that fsck invokes encounters serious inconsistencies or the filesystem type is not one of the
     above, it exits with an abnormal return status and an automatic reboot will then fail.  For each corrected inconsistency one or more lines will be printed identifying the filesystem on which the correc-tion correction
     tion will take place, and the nature of the correction.

     If sent a QUIT signal, fsck will finish the filesystem checks, then exit with an abnormal return status
     that causes an automatic reboot to fail.  This is useful when you want to finish the filesystem checks
     during an automatic reboot, but do not want the machine to come up multiuser after the checks complete.

     Without the -p option, fsck audits and interactively repairs inconsistent conditions for filesystems.
     It should be noted that some of the corrective actions which are not correctable under the -p option
     will result in some loss of data.  The amount and severity of data lost may be determined from the
     diagnostic output.  If the operator does not have write permission on the filesystem fsck will default
     to a -n action.

     The following flags are interpreted by fsck and passed along to the underlying tool that it spawns.

     -f          Force fsck to check `clean' filesystems when preening.

     -l          Limit the number of parallel checks to the number specified in the following argument.  By
                 default, the limit is the number of disks, running one process per disk.  If a smaller
                 limit is given, the disks are checked round-robin, one filesystem at a time.

     -p          "Preen" mode, described above.

     -q          Do a quick check to determine if the filesystem was unmounted cleanly.

     -y          Assume a yes response to all questions asked by fsck; this should be used with great cau-tion caution
                 tion as this is a free license to continue after essentially unlimited trouble has been
                 encountered.

     -n          Assume a no response to all questions asked by fsck except for `CONTINUE?', which is
                 assumed to be affirmative; do not open the filesystem for writing.

Peace

@Drew Reece

Agree.

Even if I managed to get many things out of my system disk Time Machine backup (a simple Seagate which has not been affected) to see what happened from a /Library/Application Support/*WD*-like point of view after the Mavericks upgrade and before the repartition of my ext. disk, I unfortunately did not get anything from the system/console logs because I looked for something too late after the issue arose. My disk got repartitioned the 4th Nov. I did my deep investigation into the the logs on the 18th. Most of the traces have been purged and are not TM-backuped as far as I can understand.

I am talking about stuff accessible from "About This Mac/More Info.../System Report/Software/"

Say the flaw is within the WD "sw", then I'd imagine some kind of inteligence and something trapped by the system logs with something like "drive mounting with the real volume name, then a trigger by that WD app to repartition the disk". Unfortunately there's no evidence of that when and after the issue happened.

I think the issue came before the WD sw intelligence kicks in and before any kind of ownership is taken by OSX (because some of you experienced the issue without any WD sw)

In my personnal case, my external drive worked just fine with reads/writes, with the WD apps, with Mavericks during 4 days with 4 reboots having the drive permanently connected. I managed to see traces in some logs that my volume was mounted with its original name.

The 4th day, for some reasons, I ejected my volume and physically disconnected the FW800 cable but left the power cable connected. Three days later I got the disk repartitioned to EFI/MyBook as soon as (I insist on "as soon as") I connected the FW800. 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.

For some weird reasons some WD sw disappeared on its own 5 days after the Mavricks install and with no ext. drives physically connected at all. Now the question is, what's the use of that WD sw except that it embeds some RAID partitioning features? Isn't it too "clever" and comes into consideration only after the disk (not the volume) is mounted?

I would have loved to see in some logs the trace of the EFI/myBook volumes mounting as you could expect to see for any disk. Unfortunately all systems logs have been purged. All my investigations came too late.

miglio74 

WD is happy to announce the release of WD SmartWare Version 1.3.6 for Mac 10.5-10.9.

WD SmartWare update highlights:

Mac release 1.3.6 (updated 11/25/2013)

http://wdc.com/wdproducts/wdsmartwareupdate/wdsmartware.asp?id=wdfGeneric&os=mac

Yes, I see same, and very interestingly note below:

http://support.wdc.com/product/download.asp?groupid=132&sid=157

For Mac

• WD Quick Formatter for Mac
• WD Drive Utilities for Mac
• WD Security for Mac
• WD Macintosh +TURBO Drivers

As the ancient Platonist Proclus once said  - "You shall know more about it by what it is not (abductive logic) than by any positive thing said of it"

In that light,... you will notice ALL possible downloads of "WD Drive Utilities for Mac"  have been removed from the WD site     (hint)

This is also a follow up to an earlier question/mention of "who knows which WD software package IS at fault"

I'd declare WD has given people the answer by what is now absent.

@Basilic, PlotinusVeritas, GetRealBro

PlotinusVeritas wrote:

 

 

 

Mac OS X version 10.9

fsck -- filesystem consistency check and interactive repair

...

  The amount and severity of data lost may be determined from the
     diagnostic output. 

So how far do peoples fsck_hfs.logs go back?

I have one in ~/Library/Logs and one in /var/log.

Any indications around the time of damage?

PlotinusVeritas wrote:

In that light,... you will notice ALL possible downloads of "WD Drive Utilities for Mac"  have been removed from the WD site     (hint)

Not true, at least any more. While it is currently very slow loading, http://support.wdc.com/product/download.asp?groupid=132&sid=157 links to Version: v1.1.7.5 of the WD Drive Utilities for Mac, Publish Date: 9/2013, which specifically lists Mac OS 10.9.x among the supported OS versions.

Once you can get the page to load, clicking the "Download" link results in a very rapid download of the ~4.6 MB zipped file.

Yes, I stand corrected , its still present.

I wonder how interlaced fsck and spotlight are in cases of ext. HD as per the earlier post:

Recent reports from a computer technician of WD reproduced (more than once) repartitioning involves - "an obvious fault in the node structure where fsck was commanded to diagnose the HFS (OSX ext. journl.) journaled file system" on the WD drive @ corruption.

~Peace

yesterday

WD is happy to announce the release of the WD Drive Manager for Mac Version 3.1.0.

• Note: the WD Drive Manager is also available for other Mac drive products.

My Passport Studio

My Passport Elite

My Book Mirror Edition

My Book Studio Edition II

My Book Studio Edition

My Book Home Edition

My Book Office Edition

My Book Premium Edition II

My Book Pro Edition II

good news at last .....

We are all in the same boat....

Just to be abundantly clear, when any external drive fails to mount in Mavericks, regardless of vendor, Apple suggests that the user run Apple’s Disk Utility to attempt to verify and repair the disk/partition. And as I have reported several times, the Mavericks Disk Utility has ALWAYS reported that this recommended process has failed. Specifically, Disk utility (running in Mavericks) has always told me that “Disk Utility can’t repair this disk. Backup as many of your files as possible, reformat the disk, and restore your backed-up files”.

In simple terms, Disk Utility has told me repeatedly that my drive is so corrupted that it is not repairable and that I should resort to other means to recover as many files as possible before reformatting the drive. Unless a Mavericks user ignores this advice given by Disk Utility (e.g. they read this thread) they believe that the information on their external drive is just as corrupted as the WD driver users who had their drives spontaneously repartitioned and the metadata overwritten with a new directory structure. The only real difference is that, in the case of non-WD driver users, Disk Utility is almost certainly mistaken. And as I have reported, it is highly likely that the information is not only there, the directory structure is probably sufficiently intact that the all of the data can be copied off of the disk. What’s more, the drive can probably be mounted by previous versions of OSX and even Mavericks so that the data can be copied using the Finder.* In some cases, the user simply has to ignore the Mavericks’ Disk Utility, be patient for a few minutes and the disk/partition will mount.

In summary, the only fundamantal difference between the plight of those that had their drives spontaneously repartitioned and those who truly believe Apple’s Disk Utility’s warnings that their external drive can not be repaired after it does not mount, is the degree of difficulty in resolving the issue. The former really have a serious problem to resolve, while the later probably don’t have a real problem as long as they ignore Disk Utility and visit threads like this one.

— GetRealBro

* This isn't theory -- I've done it with directory/file strucures as complex as a TM backup and iPhoto Library.

Unfortunately for many, it's a case of shutting the barn door after the horse has bolted.

Cheers

Pete

digitalsteel 

New Release - WD Drive Manager for Mac Version 3.1.0

Yes, now some coders need to dissect that new software like an insect in an entomology lab and see what commands were changed from the past software.

That will very likely shed light on hard drives that have been affected OTHER THAN those using WD control software (or WD RAID or WD drives)   with high certainty.

Since fsck has been mentioned in other recent posts, here is a snip from my system log while I’ve been reproducing the mounting problem…

Nov 24 12:06:02 GetRealBros-MacBook-Pro kernel[0]: hfs: node=12 fileID=4 volume=Seagate 3T device=/dev/disk3s3

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

Nov 24 12:58:02 GetRealBros-MacBook-Pro kernel[0]: hfs: node=154196 fileID=4 volume=Seagate 3T device=/dev/disk3s3

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

I don’t read system logs all that often these days. So maybe this is normal.

— GetRealBro

GetRealBro wrote:

 

This AM I plugged the FW800 cable of the troublesome Seagate 3T drive into my MBP and it didn’t mount. So I opened the Console to read the system log — NADA. I then launched Disk Utility, selected the partition and clicked Mount. After a while DU dropped down the message that it could not mount the single partition and suggested that I try verifying the disk. An all too familiar pattern. But while I was setting up the desktop to take some screen shots of the windows the Seagate 3T partition MOUNTED!

 

The Disk Utility log read…

2013-11-26 08:17:06 -0600: Disk Utility started.

2013-11-26 08:18:09 -0600: Mount of “Seagate 3T” failed

 

And the System log read….

Nov 26 08:20:08 GetRealBros-MacBook-Pro kernel[0]: jnl: disk1s3: journal start/end pointers reset! (jnl 0xffffff803a1ed8e0; s 0x41e000 e 0x41e000)

Nov 26 08:20:08 GetRealBros-MacBook-Pro kernel[0]: hfs: mounted Seagate 3T on device disk1s3

 

Interestingly the partition mounted 2 minutes after Disk Utility told me it could not mount it. BTW Disk utility continued to claim that it was not mounted, despite the fact that I could open the partition in the Finder. Patience grasshopper

 

— GetRealBro

And here is the fsck log that apparently explains the delay...

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

/dev/rdisk1s3: /dev/rdisk1s3: ** /dev/rdisk1s3

/dev/rdisk1s3:    Executing fsck_hfs (version hfs-226.1.1).

/dev/rdisk1s3: ** Checking Journaled HFS Plus volume.

/dev/rdisk1s3:    The volume name is Seagate 3T

/dev/rdisk1s3: ** Checking extents overflow file.

/dev/rdisk1s3: ** Checking catalog file.

/dev/rdisk1s3: ** Checking multi-linked files.

/dev/rdisk1s3: ** Checking catalog hierarchy.

/dev/rdisk1s3: ** Checking extended attributes file.

/dev/rdisk1s3: ** Checking multi-linked directories.

/dev/rdisk1s3: ** Checking volume bitmap.

/dev/rdisk1s3: ** Checking volume information.

/dev/rdisk1s3: ** The volume Seagate 3T appears to be OK.

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

This 3T partition has a TM backup and several 4-15GB iPhoto Libraries plus some other junk. It took fsck roughly 8 minutes to complete. Meanwhile Disk Utility said it couldn't mount the volume. Note: Disk Utility didn't say "Hang on bro. fsck is checking the volume right now. I'll let you know what it finds."

-- GetRealBro

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)

Standard set of filesystems:

       fsck -p [-f] [-m mode]

   Specified filesystem:

       fsck [-b block#] [-l maxparallel] [-q] [-y] [-n] [-m mode] [filesystem]...

Options

     -b           Use the block specified immediately after the flag as the

super block for the filesystem.  Block 32 is usually an

alternate super block.

     -f           Forces fsck to check `clean' filesystems when preening.

     -l           Limit the number of parallel checks to the number specified

in the following argument.  By default, the limit is the num-

ber of disks, running one process per disk.  If a smaller

limit is given, the disks are checked round-robin, one

filesystem at a time.

     -m           Use the mode specified in octal immediately after the flag as

the permission bits to use when creating the lost+found

directory rather than the default 1777.  In particular, sys-

tems that do not wish to have lost files accessible by all

users on the system should use a more restrictive set of per-

missions such as 700.

     -p          Without the -p option, fsck audits and interactively repairs inconsistent

conditions for filesystems. If the filesystem is inconsistent the opera-

tor is prompted for concurrence before each correction is attempted.

It should be noted that the -p option may result in some loss of data.

The amount and severity of data lost may be determined from the diagnostic

output. The default action for each consistency correction is to wait

for the operator to respond yes or no.  If the operator does not have

write permission on the filesystem fsck will default to a -n action.

     -q           Do a quick check to determine if the filesystem was unmounted

cleanly.

     -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.

     -n Assume a no response to all questions asked by fsck except

for `CONTINUE?', which is assumed to be affirmative; do not

open the filesystem for writing.

In interactive mode, fsck will list the conversion to be made

and ask whether the conversion should be done.      If a negative

answer is given, no further operations are done on the

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

if possible without user interaction. Conversion in preen

mode is best used when all the filesystems are being con-

verted at once.  The format of a filesystem can be determined

from the first line of output from dumpfs(8).

     If no filesystems are given to fsck then a default list of filesystems is

     read from the file /etc/fstab.

Inconsistencies checked are as follows:

1.     Blocks claimed by more than one inode or the free map.

2.     Blocks claimed by an inode outside the range of the filesys-

tem.

3.     Incorrect link counts.

4.     Size checks:

Directory size not a multiple of DIRBLKSIZ.

Partially truncated file.

5.     Bad inode format.

6.     Blocks not accounted for anywhere.

7.     Directory checks:

File pointing to unallocated inode.

Inode number out of range.

Dot or dot-dot not the first two entries of a directory

or having the wrong inode number.

8.     Super Block checks:

More blocks for inodes than there are in the filesystem.

Bad free block map format.

Total free block and/or free inode count incorrect.

     Orphaned files and directories (allocated but unreferenced) are, with the

     operator's concurrence, reconnected by placing them in the lost+found

     directory.      The name assigned is the inode number.      If the lost+found

     directory does not exist, it is created.  If there is insufficient space

     its size is increased.

     Because of inconsistencies between the block device and the buffer cache,

     the raw device should always be used.

http://mac.commands.com/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

fsck -p is supposed to fix minor errors automatically without human intervention

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

• Relocate hint
• Journal inode is invalid
• Journal superblock is corrupt
• Superblock has_journal flag is clear but has a journal
• Superblock needs_recovery flag is set but not journal is present
• Filesystem revision is 0, but feature flags are set
• Superblock hint for external superblock
• group descriptor N marked uninitialized without feature set.
• group N block bitmap uninitialized but inode bitmap in use.
• Group descriptor N has invalid unused inodes count.
• Last group block bitmap uninitialized.
• The test_fs flag is set (and ext4 is available)
• Last mount time is in the future (fudged)
• Last write time is in the future (fudged)
• Block group checksum (latch question) is invalid.
• Root directory has dtime set
• Reserved inode has bad mode
• Deleted inode has zero dtime
• Inode in use, but dtime set
• Zero-length directory
• Inode has incorrect i_size
• Inode has incorrect i_blocks
• Bad superblock in group
• Bad block group descriptors in group
• Block claimed for no reason
• Error allocating blocks for relocating metadata
• Error allocating block buffer during relocation process
• Relocating metadata group information from X to Y
• Relocating metatdata group information to X
• Block read error during relocation process
• Block write error during relocation process
• Immutable flag set on a device or socket inode
• Non-zero size for device, fifo or socket inode
• Filesystem revision is 0, but feature flags are set
• Journal inode is not in use, but contains data
• Journal has bad mode
• INDEX_FL flag set on a non-HTREE filesystem
• INDEX_FL flag set on a non-directory
• Invalid root node in HTREE directory
• Unsupported hash version in HTREE directory
• Incompatible flag in HTREE root node
• HTREE too deep
• invalid inode->i_extra_isize
• invalid ea entry->e_name_len
• invalid ea entry->e_value_offs
• invalid ea entry->e_value_block
• invalid ea entry->e_value_size
• invalid ea entry->e_hash
• inode missing EXTENTS_FL, but is an extent inode
• Inode should not have EOFBLOCKS_FL set
• Directory entry has deleted or unused inode
• Directory filetype not set
• Directory filetype set on filesystem
• Invalid HTREE root node
• Invalid HTREE limit
• Invalid HTREE count
• HTREE interior node has out-of-order hashes in table
• Inode found in group where _INODE_UNINIT is set
• Inode found in group unused inodes area
• i_blocks_hi should be zero
• /lost+found not found
• Unattached zero-length inode
• Inode ref count wrong
• Padding at end of inode bitmap is not set.
• Padding at end of block bitmap is not set.
• Block bitmap differences header
• Block not used, but marked in bitmap
• Block used, but not marked used in bitmap
• Block bitmap differences end
• Inode bitmap differences header
• Inode not used, but marked in bitmap
• Inode used, but not marked used in bitmap
• Inode bitmap differences end
• Free inodes count for group wrong
• Directories count for group wrong
• Free inodes count wrong
• Free blocks count for group wrong
• Free blocks count wrong
• Block range not used, but marked in bitmap
• Block range used, but not marked used in bitmap
• Inode range not used, but marked in bitmap
• Inode range used, but not marked used in bitmap
• Group N block(s) in use but group is marked BLOCK_UNINIT
• Group N inode(s) in use but group is marked INODE_UNINIT
• Recreate journal if E2F_FLAG_JOURNAL_INODE flag is set

fsck is being prompted to authorize a repair where none is needed from examination, as mentioned above single user mode may circumvent said corruption.

This is only logical theory at present

I wonder if one of those also tie in to the 'Runtime corruption' messages.

PlotinusVeritas wrote:

I wonder how interlaced fsck and spotlight are in cases of ext. HD as per the earlier post:

 

Recent reports from a computer technician of WD reproduced (more than once) repartitioning involves - "an obvious fault in the node structure where fsck was commanded to diagnose the HFS (OSX ext. journl.) journaled file system" on the WD drive @ corruption.

Do you have a link to this report? I can't find anything like that quote except from a blogger who was just wondering if his data corruption problems had anything to do with the email he got from WD about the problem with the WD software. There was no mention of repartitioning the drive, & frankly this blogger didn't seem to know what he was talking about well enough to be a technician employed by WD.

I'm also not quite sure what you think Spotlight has to do with this issue. Spotlight just extracts metadata from within files & from the file system & stores that in normally invisible "V-100" databases in a form optimized for rapid retrieval during Spotlight searches, but those files are stored on the drive just like any other files, so fsck treats them no differently, nor would it be invoked during a drive reformat since there are presumed to be no files for it to check.