Hi. Unix rookie here. Been looking for a few days for reference documents on how BSD UNIX lays the logical file format onto a disk. Goal is to view/edit with hex editor for data repair. Lots of docs are available for how to use Unix commands (like xxd), but I want to learn the map of how Unix stores the file header and file data and cluster information on the hard disk. I've asked on a few forums and emailed companies (like R-tt regarding R-Studio for Mac) and have no answer yet. Anyone know where I can read about this?
I'l give this a try but I do not quite get the point, so I may be way off:
One of your assumptions needs a tuneup. How inodes (one the objects you want to learn about) are stored is implementation dependent, so ffs filesystems may have a different structure from ufs filesystems.
There is no one single fits-everything kind of answer.
What you have to do is to get the source code for the filesystem(s) you want, then look in the .h files for structures. Look for inode, and vnode. This stuff will be in driver source for a particular filesystem flavor.
You can get a lot of this information and write simple C programs using
dirent.h
which is a wrapper to calls that show directory entries, one of the places you need to look. Structures on the disk are a whole lot tougher to navigate through. And directories have file structure on top of the file metadata.
Now my turn:
Why are you going this way? Please tell us what you want to accomplish. Not how you think you can do it.
Answers like
' I need to see the actual list of segments for a file and their absolute offsets'
are what we need.
1 Like
Thanks Jim. I was thinking it might be as difficult as you say. When I've posted the complete situation over the past few days, I get responses that suggest I should not want to know this or do this. As an enthusiast I like to explore and learn, so thought I would try to ask a much more direct technical question to avoid being scolded. 
Attached are several of my posts from a more thorough thread I started last week that might answer any questions you have. Sorry it is so long.
I've had these similar data errors on a MacBook 2006 10.6.8, a MacBook 2010 10.8.x, and a two week old MacBook Pro 10.10.5. The older ones have been cleaned up with install of OS. Because of our hack history here I was trying to learn more about this.
Fixing file permissions by editing raw disk blocks is like fixing a broken clock with a scanning-tunneling electron microscope. A monumental task, inefficient use of your time, too close to see the forest for the trees, and extremely unlikely to accomplish anything.
If those folders have become files, I would suspect they were renamed or deleted and files created in their place, rather than disk corruption or hacking turning them into files. Hacking is unlikely to accomplish something that even the kernel cannot, and I doubt you can "turn them back". Perhaps you could move them out of the way and see if itunes can create new folders in their place.
1 Like
Thanks!! Finally had time to take a look at the man pages for inode and dirent and it is exactly where I wanted to start learning. How perfect. I feel like I'm on my way.