Talk:HFS Plus

From Wikipedia, the free encyclopedia

 This article is part of WikiProject Macintosh. This means that the WikiProject has identified it as an article pertaining to Apple Computer, but is not currently working to improve it. WikiProject Macintosh itself is an attempt to improve, grow, standardize, and attain featured status for Wikipedia's articles related to Apple Macintosh and Apple Inc. We need all your help, so join in today!
Start This article has been rated as Start-Class on the assessment scale.
High This article is on a subject of High-importance within Macs for inclusion in Wikipedia 1.0.

Isn't the official name of the file system HFS+, not HFS Plus?

Apple use both names interchangeably: http://developer.apple.com/technotes/tn/tn1150.html AlistairMcMillan 08:34, 21 Sep 2004 (UTC)

Contents

[edit] Sectors/clusters

Sector as the smallest unit is incorrect (sectors being drive-related and are usually 512 byte). Clusters are somewhat more correct. I believe the term Apple uses is Allocation Block (it's in TN1150 as that). - Pete C ✍ 13:42, 7 May 2005 (UTC)

[edit] n-forks

HFS Plus permits filenames up to 255 characters in length, and n-forked files similar to NTFS, though the Mac OS has never implemented support for forks other than the data fork and resource fork.

With Tiger, apple is now using a 3rd fork for Metadata. they also use this matedata fork for ACLs.
I'll let someone who can put it in better words (and context) than I to put it into the artical :)
Please identify yourself next time you talk. There is no probe that Tiger is using a 3rd fork for metadata, and Spotlight is proven to use regular files for storing its metadata (for being filesystem independent). Claunia 06:13, 20 August 2005 (UTC)
Tiger has new metadata features, but not really using a 3rd fork. There is a lot of detail here: http://arstechnica.com/reviews/os/macosx-10.4.ars/7 --Jwwalker 04:53, 24 August 2005 (UTC)
I suppose no one of you are confusing the "metadata zone" with real metadata, isnt it? —Claunia 22:36, 24 August 2005 (UTC)
Hard to say, because I am not familiar with your terms. As I understand the Ars Technica article, not all of the metadata is in the same place, i.e., the new extended attributes are in a different area from the old metadata such as file type, creator code, and modification date. --Jwwalker 02:54, 25 August 2005 (UTC)
Read the HFS+ specification and clarify yourself —Claunia 22:46, 25 August 2005 (UTC)
Actually that second posting by Claunia reminded me of the line in Nemo 'It's like he's trying to speak to me, I know it.' ☺ Barefootguru 23:42, 25 August 2005 (UTC)

[edit] fragmentation

There should be some more discussion regarding fragementation on HFS+ volumes. This is a rather significant issue with HFS+: http://www.kernelthread.com/mac/apme/fragmentation/

If you think that fragmentation is a significant issue in HFS+ you just didn't checked other filesystems fragmentations. I think it is not is not an issue, just a feature to name (the 10.3 transparent defragmentation). Appart from that, fragmentation is created by the implementation and not by the filesystem itself so it is not matter of discussion on this article, for example HPFS under OS/2 presents almost no fragmentation but HPFS under Windows NT heavy fragments itself. Claunia 06:11, 20 August 2005 (UTC)

[edit] Infobox

Ghakko added an infobox to replace the filesystem features table while AlistaimMcMillan and me were working on another.

I think, people should select the best for definitive implementation in all filesystem articles.

Ghakko's one is Template:File_system while mine is Template:Infobox_Filesystem.

Personally I think the second is more consistent with other Wikipedia infoboxes.

Regards, Claunia 06:05, 20 August 2005 (UTC)

[edit] Typo?

The doc says: "Max file size 8 EiB, Max volume size 8 TiB" Is that a typo? Why support file sizes that can't fit on any volume? http://en.wikipedia.org/wiki/Comparison_of_file_systems says both are 8 EiB -- smcbride

Fixed. Seems to have been just a typo. AlistairMcMillan 16:05, 25 August 2005 (UTC)
I have a question with the phrase "HFS Plus is an improved version of HFS, supporting much larger files (64 bit length instead of 32 bit)". This seems wrong, or at least misleading if taken in the literal sense. HFS+ must obviously support files greater than 64 bits in length, or it wouldn't be terribly useful; I think the 64 bits must be in reference to some sort of address space? To be honest I'm not sure what is being said there, but it's confusing and I hope that somebody who is familiar with the subject can clear it up. Thanks! -- Kadin2048 15:47, 6 January 2006 (UTC)
The maximum volume size is UInt32 (32 bits) of blocks of up to UInt32 (32 bits) bytes (4GiB) each.
The maximum file size is UInt32 blocks or UInt64 bits.
So both maximums are 16EiB.
—Claunia 19:57, 6 January 2006 (UTC)

[edit] Alternate FS/OS Inter-operability

I was wondering if there were any projects or implementations for other Operating Systems and File Systems to read/write/modify HFS+. For example in the NTFS article it states that Linux and some other OSs have implemented features that alow them to read and in some cases write to NTFS. Are there any such efforts for Windows, Linux, BSD to muck around with the Mac FS? --Zigbigadoorlue 01:14, 8 January 2006 (UTC)

There is full read/write support for HFS and HFS+ in the Linux kernel from a long time ago, and there are commercial products available for Windows (MacDrive for example), for *BSD I don't know but I think the userspace hfsplusutils can be compiled on them.
—Claunia 01:03, 21 February 2006 (UTC)
Could someone (not me) include this bit of information in the article I think it would be a useful addition.
—Zigbigadoorlue 06:37, 1 March 2006 (UTC)

[edit] Journaling

What type of journaling does HFSJ use? Bbatsell 09:06, 14 January 2006 (UTC)

Metadata only. AlistairMcMillan 10:42, 14 January 2006 (UTC)


[edit] 255 chars?

I've never seen a filename able to exceed 31 characters on the Mac OS. Are we sure of this..? —The preceding unsigned comment was added by Angelic Wraith (talk • contribs).

If you have access to a Mac try it for yourself. We are very sure of this. [1] AlistairMcMillan 23:38, 22 March 2006 (UTC)
31 chars is what you get to see when you are using the old Mac OS (versions up to 9), while the new Mac OS X versions can show you up to 255 chars in a name. Actually, since Mac OS 8.1, other programs than the Finder can also use/show file names with more than 31 chars if the disk is formatted in HFS Extended format (versus the older HFS Standard format). One of those programs is Kilometre Browser. Tempel 07:28, 23 March 2006 (UTC)
I'm not sure what your point is. What is the problem? This page is talking about HFS Plus. You do realise we have a separate page for the old version at Hierarchical File System. AlistairMcMillan 07:47, 23 March 2006 (UTC)
Of greater interest is perhaps the fact that "255 characters" refers to "255 16-bit code points after HFS decomposition", which can be significantly less than 255 "characters" in the mind of the user. For example, the heavily ornamented greek character ᾅ (0x1f85) must be decomposed[2] as four (!) 16-bit values, so that a file name consisting of this letter only can be no longer than 63 "characters". Less extreme examples include é and ö, which both decompose as two 16-bit values. --Woseph 13:19, 28 June 2006 (UTC)

[edit] Possibility to recover deleted files

I was searching info about the possibility to recover files after an "empty trash" command. Is it posssible to recover files with original names as I do with my PC? I tried many programs but I could not find one that accomplishes this task. Thank you —The preceding unsigned comment was added by 151.28.18.174 19:40, 20 April 2006 (UTC)

I like Versiontracker for Mac OS and Mac OS X software, but it would probably be more appropriate to ask your question on a Mac-specific forum. —204.42.16.173 01:48, 3 May 2006 (UTC)
Interesting thread on this topic. —204.42.20.254 19:33, 9 May 2006 (UTC)

[edit] Bad Block's structure is a file

Currently it says that the bad blocks's structure is a "b-tree". I find that misleading and unspecific. While part of the bad blocks information is stored in a b-tree (but not all of it), the information about bad blocks is not organized in a b-tree. Instead, it is organized as a special file: all blocks being part of that file are identified as bad blocks. So, I propose to change the description from "B*-Tree" into "special file". (and what's the answer for HFS Standard, BTW, as I do not remember?) Tempel 08:27, 3 September 2006 (UTC)

Could you provide a source to back this up? AlistairMcMillan 15:30, 3 September 2006 (UTC)
If I'm reading TN1150 correctly, there isn't an actual bad block file. Just records in the Extent Overflow file and the Allocation file. AlistairMcMillan 15:33, 3 September 2006 (UTC)
Well, as you can clearly read under [3], it's called a bad block file. But whatever. That's not really the point of the discussion.
Alistair, would you agree with me that changing the current description in which it specifies that bad blocks are organized in a B-Tree structure is wrong and should be changed? My suggestion is to either change it to "special file" or "special list of extents". I'd prefer the first, because that's more general and could also be applied to other file systems where appropriate without causing confusion whether the technique is the same. -- Tempel 12:12, 4 September 2006 (UTC)
Seems to be the same for HFS as well. [4] AlistairMcMillan 15:36, 3 September 2006 (UTC)
But the MDB does not provide any way to mark bad blocks. And the Files-371 technote you mention is very old and outdated and refers only to Floppy disks, I believe. A "Disk utility" might not have a chance to know that mapped-out blocks are actually meant to remain mapped-out and not to be recovered. With HFS+, where those blocks belong to a special file, the disk util can know not to "free" those blocks again, but in HFS Std this was not possible, IIRC, unless one would create a normal file, probably marked hidden, with a special name such as "this file contains bad blocks - do not delete it". Tempel 12:22, 4 September 2006 (UTC)
Correcting myself: The Technote says "A special file ID (5) is used for these extents." - I remember now that disk utilities which would check the consistency of the volume were supposed to ignore files with an ID below 16 - and consider them special (and valid) system files. So, yes, HFS uses practically the same means to mark bad blocks as HFS+ does. Tempel 12:28, 4 September 2006 (UTC)

[edit] 68k CPUs and HFS Plus

This article needs to note that the only Macintosh computers with 68k CPUs that are capable of using HFS Plus are ones with a 68040 or 68LC040 CPU and they have to be running Mac OS 8.1. Also, the boot partition on these Macintosh computers (where OS 8.1 is installed) must be formatted as HFS Standard. Perhaps the text of the Where_have_all_my_files_gone? file could be included in that section?

Please sign your messages.
You can use a software emulator that allows unsupported install of MacOS 8.1 in any 68020 or 68030 Macintosh computer, and also, you can use Linux/m68k with HFS+ partitions. Really there is never a reason that limits a filesystem to any CPU.
However you can note that boot support under Mac OS works only with PowerPC Macintosh.
—Claunia 14:46, 5 October 2006 (UTC)

[edit] Truncating filenames with Classic OS

Care must be taken to not alter files with names over 31 characters when accessing them from Mac OS 9.2.2 or older, when using the Finder or any application that is not written to use the longer filenames.

Otherwise the names will get cut down to 31 characters, not simply cutting the name at 31 but using a 'shorthand' similar to how Windows stores an 8.3 name for every file with a name longer than 8 characters, a dot and a 3 character extention. Ie, if you dual boot 9.2.2 and OS X, don't edit the ID3 tags on your MP3 collection from within 9.2.2! You'll find every one you edited has the longer than 31 character name wiped out.

Actually, the problem behind this is a sign of poor programming (i.e. not following the guidelines), even for older apps not knowing of long files names: If an app supporting only the old (short-name) APIs, it would still preserve the original file name when changing a file if it would not delete the original file and recreate a new one, but instead would really modify the original file in place. Ergo, a properly written program to edit MP3 tags could still do it right despite not supporting HFS+ long file names explicitly. But, apparently, many programs did this wrong, but there may actually be programs that do not destroy the long name when editing a file under OS 9 --Tempel 07:42, 3 October 2006 (UTC)

[edit] Which OS versions support which sizes

At the end of the History chapter, the information about support in various OS version appears wrong to me. E.g, starting with OS 8.1 (not 9 as the article suggests) HFS+ was introduced, and along with it a new API that provides functions to access files with 64 sizes. Or so believe to remember. The Finder and most other apps did not deal with this well, but from a programmer's point of view the current information in the article is partially incorrect.

I'd have to do more research to come up with the correct values and versions, though.

Does someone else know this better already?

-- Tempel 15:17, 29 November 2006 (UTC)

[edit] GPT Identifier

The article says that the GPT identifier for a HFS+ file system is: 48465300-0000-11AA-AA11-00306543ECAC. However, I'm writing a program to read the GPT partition table, and on my MacBook, the GPT identifier seems to be 00534648-0000-AA11-AA11-00306543ECAC. So the first "field" (4 bytes) and the third field (2 bytes) seem to be byteswapped. I have checked the endianness of what I'm reading, but it seems to be ok. Besides, the Microsoft and EFI partition identifiers match perfectly. Got any ideas why I'm experiencing this? Because I'm thinking there is an error in the article... but I obviously need more data to prove that. --Unsound 21:35, 1 April 2007 (UTC)

Retrieved from "http://en.wikipedia.org../../../h/f/s/Talk%7EHFS_Plus_0aca.html"