I/O errors accessing a Yosemite volume

[TheBSDGuy]

I noticed this a few days ago. I was trying to set up a development system for Yosemite when I stumbled upon a file named "[" which I'd never seen before. It turns out it's just a copy of the Unix "test" command.

During that little sidetrack, I noticed that when I tried to read or get infe on the "[" file the OS would report "input/output error." I assumed there was a bad block on the drive because if their is, that's usually the message you get from the command line. I rebooted from my Mountain Lion volume, which I use as my base OS now and used Scannerz to test the hard drive. Scannerz found nothing wrong - NOTHING!

At that point I had just stopped because someone else answered the "[", the drive looked OK, and I thought it was just an oddity. Last night I returned to trying to set up the partition for development and once again, I'm getting the input/output errors, but on everything that's on Yosemite. This is mounted from a Mountain Lion partition.

I wrote a little program with super user level authentication and it wasn't allowed to open the file on the Yosemite partition to just read it. It's like the entire drive has been "blocked off" from access.

I'm not a security guy, and hadn't really put a lot of time into looking at Yosemite's underlying features. Are these being caused by resource fork settings and can they be changed easily?

Right now it's sort of a PIA trying to deal with this thing.

 

[dsemf]

Is the Yosemite partition using CoreStorage? Is it encrypted?

diskutil list
diskutil cs list

DS

 

[TheBSDGuy]

I have 2 Yosemite volumes, one is Core Storage the other is a standard formatted HFS+ volume. The same thing happens to each of them. This only happens when I try to access them as volumes mounted under Mountain Lion. I haven't tried it with other OS versions, and I haven't confirmed whether or not if I boot from a Yosemite volume, the other Yosemite volume exhibits the same characteristics.

Am I the only one that has this problem, or am I just the first one that's publicized it?

 

[ZVH]

SCSC just released, as within the last few hours, the Scannerz update that includes the Phoenix version that's Yosemite compatible. They make some notes addressing your problem.

Apparently Yosemite is not liked by earlier versions of OSes if you boot from them. According to the release notes, if you boot from anything earlier than Mavericks, you cannot properly access a Yosemite volume. They say in Mountain Lion you can see files, but you cannot manipulate them. On earlier OS versions, Yosemite volumes, whether Core Storage or regular HFS volumes may not even show up in something like Disk Utility.

I have a Snow Leopard partition hanging around because I have an old graphics PPC program that I can use Rosetta to open and still make use of it. For a test, I booted it up and sure enough the Yosemite volume didn't show up in Disk Utility just like they said. Interestingly, Scannerz picked it up but like the notice said, Scannerz only cares about hardware since that's what it's testing.

If I understand it properly, if you want to from a volume that's based on an earlier release, the way to do it is to boot from Yosemite and then copy the files from the older OS based volume to the Yosemite based volume. The other way around won't work.

I didn't test anything else so I don't know what else Yosemite is incompatible with.

 

[TheBSDGuy]

I got the update earlier today.

Poor pitiful me. Sitting here beating my head against the wall thinking there was something wrong with my system. Now I know.

Thanks for the pointer.

 

[KoolAid-Drink]

Wow, seriously? That doesn't sound right. If Yosemite was installed on a regular HFS+ volume (not Core Storage), then shouldn't files and all be viewed from another version of OS X? I mean, SL was easily able to access Mavericks files without an issue. What could have changed in Yosemite's specific implementation of HFS+?

SCSC just released, as within the last few hours, the Scannerz update that includes the Phoenix version that's Yosemite compatible. They make some notes addressing your problem.

Apparently Yosemite is not liked by earlier versions of OSes if you boot from them. According to the release notes, if you boot from anything earlier than Mavericks, you cannot properly access a Yosemite volume. They say in Mountain Lion you can see files, but you cannot manipulate them. On earlier OS versions, Yosemite volumes, whether Core Storage or regular HFS volumes may not even show up in something like Disk Utility.

I have a Snow Leopard partition hanging around because I have an old graphics PPC program that I can use Rosetta to open and still make use of it. For a test, I booted it up and sure enough the Yosemite volume didn't show up in Disk Utility just like they said. Interestingly, Scannerz picked it up but like the notice said, Scannerz only cares about hardware since that's what it's testing.

If I understand it properly, if you want to from a volume that's based on an earlier release, the way to do it is to boot from Yosemite and then copy the files from the older OS based volume to the Yosemite based volume. The other way around won't work.

I didn't test anything else so I don't know what else Yosemite is incompatible with.

 

[TheBSDGuy]

I'm beginning to wonder if there aren't still a few bugs with the OS.

When I did the orginal installs I cloned a Mavericks volume over onto a spare partition and then installed Yosemite over that. I can access and modify files in my own folder that were originally there in the first place. The problems seem to occur with anything that Yosemite installed, and it seems to have something to do with compression and resource forks.

Another thing I noticed is that the some of my own volumes are now owned by another account. It then dawned on me that Yosemite likely switched the user ID numbers during install.

This is beginning to look like a squirrelly operating system. Are these "features" or bugs?

 

[grahamperrin]

HFS and HFS Plus compatibility with Yosemite and other current distributions

… What could have changed in Yosemite's specific implementation …?

I don't know what (I don't plan to look in detail), but if HFS is already legacy from Apple's perspective, then I should assume that Apple's focus is less on broad compatibility with all current distributions of the OS (that probably excludes Snow Leopard); more on something other than HFS Plus.

Storage and file systems, HFS and legacy, kSKDiskRoleLegacyMacData and kSKDiskTypeHFS

 

[ZVH]

The tendency for Apple to maintain backward compatibility with past releases is waining.

 

[ONFL]

Hi BSD Guy (and others as well)

I apparently have the same kind of problem as you: after installing 10.10 on an external drive, I boot back into my old 10.7 system on my internal drive, and now I can't read the files installed on the external drive (I can only walk through the directory hierarchy). I can get info about them doing e.g. "ls -al@ that_file", but if I say "cat that_file" or "hexdump that_file" or "cp that_file some_other_place", etc..., it does not work and I always get the "input/output error" message instead. The funny thing is that I can copy the file to my internal drive using the Finder (instead of cp), but then if I try to access the copy I get the same error messages. I thus tend to believe that the problem rests in the files themselves and not in the volume. I notice that those uncopyable files all have some extended attributes set, as can be checked by the "@" option on the "ls" command. Other clues ?

Thanks in advance for any help.
Olivier

 

[TheBSDGuy]

From what I can tell and from what the SCSC people told me, it has to do with compression, and the fact that Yosemite is using some type of file compression some earlier OSes don't understand.

The compression part is something I don't fully understand on a new Apple OS, and maybe someone can chime in here to clarify. Apparently when a new OS is installed the files are somewhat compressed in a manner similar, but not identical, to what you have with a zipped or gzipped file. What I don't know is that when the files are opened and used by the OS, are they then uncompressed and become "normal" files, or do they stay compressed. I'm uncertain of this.

In any case, files and devices on a Unix system, which is what OS X is, are treated alike. When a file is opened it's pretty much up to the kernel to decipher what will be done with it. Since the kernel doesn't understand or recognize the compression, it doesn't recognize the file as even being a file at all, and hence throws an I/O error. If you open up a terminal and use the "tail" command to follow the log file /var/log/system.log, on older OSes you'll actually see kernel error messaged popping up in the log when you try to access a Yosemite volume, but you must boot from Mountain Lion or earlier.

I think this is just the way it is. There was something similar with Leopard when Snow Leopard and newer came out. In this case if you booted from Leopard, some of the files that were visible on Snow Leopard and later would not show up on Leopard. That's from memory, and it's getting a little foggy.

 

[grahamperrin]

AppleFSCompression

Also known as HFS+ compression.

Native File System Compression on Mac OS X (archived 2011-09-17)

Posted by me to Apple Support Communities in December 2012:

Re: Copying files from one external HD to another : error -8084

 

[ZVH]

Years ago I was under the impression that resource forks were a legacy item that were to be discontinued in the future. I don't know where, but I think 4 or 5 years ago I read that.

So now they're being revived????

 

[grahamperrin]

Misunderstandings about use of resource forks are fairly commonplace … explanations are probably off-topic.

 

[TheBSDGuy]

I'm not sure they're technically using resource forks, but extended attributes. I've been reading a little on this but not a lot. I think it just qualifies as a "You can't do this with Yosemite" type of deal.

 

[grahamperrin]

AppleFSCompression, resource forks and extended attributes

I'm not sure they're technically using resource forks, but extended attributes. …

From documentation for fileXray:

"… Depending on the file’s size and potentially other factors, the compressed data resides either in the file’s resource fork or inline within an extended attribute that’s set on the file. …"

 

[jallanbloomfiel]

AppleFSCompression, resource forks and extended attributes

I run a dual boot partitioned drive with 10.10.x (x=Yosemite not booted now)
Whatever OS is up, I mount the other OS partition so I can access files in my User directory.

Here are the consistencies I've noted:

1. When you try to open Yosemite system files installed by the Yosemite installer from snowleopard, you either get an i/o error if you're root and "permission denied" if you're an ordinary user.
   
   
2. When booted in Yosemite, if you WRITE the file from an application (assume a text file), and then boot the older OS (in my case, snowleopard), I am able to open the file from snowleopard.

Try this for yourself:

1. With snowleopard booted, log in as root and use terminal or finder to navigate to
   usr/share/man/man1 on the Yosemite disk.
   
   
2. Try to open the file cat.1 with cat, vi, or Textedit.app. It will fail with the i/o error.
   
   
3. With Yosemite booted, log in as root and use terminal or finder to navigate to
   usr/share/man/man1.
   
   
4. Open the file cat.1 with vi or Textedit.app and then write the file back out to the same file name in usr/man/man1.
   
   
5. Boot snowleopard and log in as root. Navigate to the Yosemite disk once more to
   usr/share/man/man1. Open cat.1 with cat, vi, or Textedit.app. You will be able to open and read the file.

Conclusive conclusion: I don't have any! Maybe originally installed system files are specially compressed in a format the Yosemite kernel recognizes and writing (modifying) the file tells the kernel to decompress the file. ls -l doesn't give any clues. Copying the files across disks to snow leopard (tried cp and the finder) without modifying the file contents (writing from cp or Textedit.app) will still produce the i/o error.

At least I've been able to produce consistent behavior. User files seem to copy happily from Yosemite to snow leopard, apparently because they haven't been compressed (or maybe have some undocumented bit hasn't set in the filesystem metadata because I've never observed anything visible happening with ACLS or extended attributes).

Maybe someone else has some better ideas based on the consistent behavior I've been able to produce

 

[TheBSDGuy]

I run a dual boot partitioned drive with 10.10.x (x=Yosemite not booted now)
Whatever OS is up, I mount the other OS partition so I can access files in my User directory.

Here are the consistencies I've noted:

1. When you try to open Yosemite system files installed by the Yosemite installer from snowleopard, you either get an i/o error if you're root and "permission denied" if you're an ordinary user.
   
   
2. When booted in Yosemite, if you WRITE the file from an application (assume a text file), and then boot the older OS (in my case, snowleopard), I am able to open the file from snowleopard.

Try this for yourself:

1. With snowleopard booted, log in as root and use terminal or finder to navigate to
   usr/share/man/man1 on the Yosemite disk.
   
   
2. Try to open the file cat.1 with cat, vi, or Textedit.app. It will fail with the i/o error.
   
   
3. With Yosemite booted, log in as root and use terminal or finder to navigate to
   usr/share/man/man1.
   
   
4. Open the file cat.1 with vi or Textedit.app and then write the file back out to the same file name in usr/man/man1.
   
   
5. Boot snowleopard and log in as root. Navigate to the Yosemite disk once more to
   usr/share/man/man1. Open cat.1 with cat, vi, or Textedit.app. You will be able to open and read the file.

Conclusive conclusion: I don't have any! Maybe originally installed system files are specially compressed in a format the Yosemite kernel recognizes and writing (modifying) the file tells the kernel to decompress the file. ls -l doesn't give any clues. Copying the files across disks to snow leopard (tried cp and the finder) without modifying the file contents (writing from cp or Textedit.app) will still produce the i/o error.

At least I've been able to produce consistent behavior. User files seem to copy happily from Yosemite to snow leopard, apparently because they haven't been compressed (or maybe have some undocumented bit hasn't set in the filesystem metadata because I've never observed anything visible happening with ACLS or extended attributes).

Maybe someone else has some better ideas based on the consistent behavior I've been able to produce

I believe modifying some files will strip the resource forks/extended attributes. It would be nice if Apple had better documentation on this but all I seem to find are links to old HFS manuals that are now in their sections for ancient documents.

 

[vexorg]

I found copying problems with yosemite compared to mavericks and lion. Yosemite throws up problems that were never there before, like permission needed (user password) and error -36 when copying folders (manually copying the files inside is no problem). It's a real PITA when doing a manual backup compared copy and leave it before.