Mybook studio raid 0, empty after installing Mavericks

10.9.1

I've received new info from Seagate during a conversation about concerns about their kernel-level software and Mavericks. It's a shame Western Digital aren't as good as Seagate at giving real answers!

Here's what they've revealed:

I understand you caution, concerning external drives with 10.9 and 10.9.1, the issue is clearly deffined, as the OS is writing an UEFI partition onto the drive, without preparing it accordingly. As this partition is written into a section of the drive, that is normaly occupied by the MBR, and is not cleared during the installation process, all essential information about all data, that is on the drive is lost, and renders the data completely unreadable. This is no incompatibility of the drives with Mavericks, all drives should be compatible, this is a change of the requirements of the OS to the drives, used with it, expecially those, that are connected to the System during update process.

After a de-initialisation and re-intitialisation as GPT with UEFI and formatting under Mavericks, those drives will work again perfectly fine.

The data will be lost, so to have a backup of the external drive is recommended during the update and the first use of the external drive with Mavericks.

Interesting post 🙂

If Seagate are correct the affected disks should have been formatted with a Master Boot Record partition table (MBR).

Does anyone with an affected disk have any evidence of this? Obviously the disk will now have a GPT table after 10.9 breaks it. I wonder if this can help the issue be reproduced, e.g. format with MBR & hope 10.9 'works it's magic', perhaps have them connected during an install of 10.9, since the Seagate tech said 'that are connected to the System during update process'

'diskutil list' in Terminal will show the hidden UEFI (EFI) partition and 'partition scheme'.

Whilst it's possible to have 2 partition tables (GPT & MBR) it's not the default & is not recommended - it's usually when trying to make disks multi-boot into other OS's (Linux & Windows can support MBR & GPT tables for booting). UEFI is the tiny partition that holds a boot loader (where required - e.g. not OS X).

I thought Disk Utility used GPT as the default format for external disks (USB thumbdrives seem to get either partition table type). It's been like that for sometime too.

Assuming Seagate are correct it makes me wonder how so many users could have had a MBR table on external disks, I guess it could be the default table that is supplied on those disks?

Reading this thread with great concern, obviously.

Do I understand correctly that this problem ONLY exists with drives running in a raid configuration?

--------------

I "upgraded" to Mavericks a few months ago (what a piece of garbage) and have about 15 external backup drives, mostly WD Blacks. However, I backup manually, then use CCC to make 2 clones. (three drives total, for each source drive.)

So far, I haven't had any problems, except for the insanely infuriating "ds.store" issue, for which someone at Apple should be in jail.

Anyway, should I still be considering FW updates, or re-initializing of all my drives?

- thanks

Nope it does not exist only with RAID drives.

I am shocked that the auto-formatting problem still exists for some people even without having any WD software installed. I have to ugrade to Mavericks anyways, eventually...

Same disaster happened to my external ORICO RAID1 drive. I was left with 1.5T empty volume named "My Book". This drive is connected via USB to iMac 24 on 10.9.2. WD software was installed (Drive Manager and Smartware) before the incidents. I have filed a service request with WD and waiting for the reply.

From reading the forum, it seems that there is no recovery software that could recover the files WITH the filenames and folder structure. Is this understanding correct? Thanks.

dlam06 wrote:

WD software was installed (Drive Manager and Smartware) before the incidents.

Just to be sure: you mean the old WD software was installed?

Yes. Old WD software was installed last year when I install the Mybook Live. That was before (inplace) upgrade to Mavericks and I have not notice from the news on the possible conflict between WD software and Mavericks until my drive was erased.

There are many different recovery software programs out there but It's unlikely recovery software will be able to recover the file structure, folders and file names. In any case I recommend Data Rescue 3. There is also test disk, which is great, and free, but requires some knowledge of using the terminal. http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

I've been reading this thread for months with the utmost curiosity. Today it has regained my attention, seeing 10.9.2 has not addressed the issue.

Forgive me for maybe repeating a question, but this thread is so long and old...

It is obvious that the data loss here has something to do with residual/migrated WD software. All of us here are searching for the missing factor, in order to be able to replicate the issue. On several international Apple fora I have been unable to detect any similar complaint, and I believe PlotinusVeritas in this thread has certainly done his utmost to replicate the issue, to no avail, alas.

Thence my question: did any of you affected here exclude the affected drives from being indexed by Spotlight? Did any of you affected here exclude the affected drives from being backed up by Time Machine? I am beginning to think the issue here has something to do with Spotlight indexing.

The reason being: various reports reaching me of unresponsive Time Machine backups under both Mavericks versions, all seeming related to Spotlight indexing of the external TM drive. You all know TM relies heavily on Spotlight.

Am I seeing ghosts or might this be a clue?

I can confirm that there is a RELATED problem with non-raided drives:

I use many WD black caviar drives for backup, via usb (no eSata on my $4,000 Mac desktop, thanks Apple!)

I typically have three extrenal drives for each files group, and backup by hand. However, the "DS.store" problem (thanks, Apple!) is making me insane, so yesterday I decided to try CCC to "update" one of my drives:

note: I checked with a CCC tech, before proceding, to see if this would be safe. I was told yes. He was wrong.

-------------------------

Drive #1 had all my data. Drive #3 had just be fully erased, and then had all of the data from drive #1 cloned onto it, using CCC. This worked fine.

Drive #2 already had about 99% of the data from drive #1 on it, tranferred by hand. (by dragging.) I had CCC set to NOT erease anything that differed on the destination drive, so it SHOULD have simply added what was missing.

I started the procedure, and went to have coffee. When I came back, I noticed that, instead of simply adding the missing 2-3 GB of data to disk #2, CCC had already transferred about 200 GB ! I looked at Drive #2 and saw that, while all the folders were still there, about 1/3 of my data had been wiped out. The folders were empty!

@#%%@$#%

So now I have to drag back all that data, which thanks to the Mac's DS.store problem, will take me all day.

Additonally, if any files have gone bad on Disk #1, and if I didn't have Disk #3, they would be gone forever.

Good Lord.

^ An important note about the above problem:

My Disk #3 had been re-initialized under Mavericks, while Disks #1 and #2 had been initialized under Mountain, or possibly even leopard.

My guy tells me that CCC, while it works with Mavericks, isn't able to see file structures (or forks, or whatever) created under earlier OS's.

If anyone knows more on this, PLEASE let me know.

Cableaddict

Can you elaborate on the .DS_Store issue? I know what they are but not what the issue with 10.9 is.

Also elaborate on what your guy said. My understanding is that the volume structure is still HFS+ extended on 10.9 & as such should be the same as 10.8 etc. Apple probaby changed Core storage & added other metadata to the system, but that may all be enclosed within the HFS structure that is stored on disk?

It does look to me that 10.9 adds some kind of flag that prevents earlier OS's modifying partitions, so perhaps 10.9's HFS is different. I saw it on 10.6.8's Disk Utility.

Data & resource forks were a very old Mac OS feature (pre OS X), could your guy may be mixing them up?

They are so old that most users don't need to care about them, those that do need them will have the data on old formatted disks.

Well, Cableaddict: this may be some important bit of information: Mavericks not playing well with data from migrated systems.

My guy tells me that CCC, while it works with Mavericks, isn't able to see file structures (or forks, or whatever) created under earlier OS's.

Probably has to do something with SMB2, recently implemented on Mav. Don't know the fine print.

But probably again has nothing to do with the issue at hand. Data and Resource forks used to be the two constituents in the OSX filesystem.

http://en.wikipedia.org/wiki/Resource_fork

http://en.wikipedia.org/wiki/Fork_(file_system)

And yet this: http://forums.appleinsider.com/t/157993/apple-shifts-from-afp-file-sharing-to-sm b2-in-os-x-10-9-mavericks

Here is your significant change: apple file sharing to smb2 under Mavericks. Once again: probably nothing to do with the issue at hand. But great thanks for mentioning it!

And you know what: with all these structural changes, who knows what may go wrong, especially with migrated files.

Apple listed in its Mavericks Features that it was using an updated MetaData standard. I believe that the new standard found bad code in the 3rd party manigment software that the older standards missed and this may have led to the MetaData corruption issue. People that reformatted their Time Machine drives with Disk Utiliy before using them have yet to have any problems.