Talk:HFS Plus/Archive 1

Archive 1

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)

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)

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)

Journaling

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

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

255 chars?

I've never seen a filename able to exceed 31 characters on the Mac OS. Are we sure of this..? —Preceding unsigned comment 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)

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)

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)

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)

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)

The article is correct. See Technical Note TN2166: Secrets of the GPT at Apple's developer website.—204.42.27.32 22:46, 14 April 2007 (UTC)

NFD ?

The article discusses "NFD" without expanding on what that acronym means. Could the original author (or anyone else who knows the meaning) please clarify?

Stian Oksavik 03:56, 11 June 2007 (UTC)

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)

According to http://developer.apple.com/technotes/tn/tn1150.html, the maximum file size is 2^63 bytes, which would be 8EiB. I've changed it in the table and the infobox and added the link under external links.

Smidgie82 20:09, 23 July 2007 (UTC)

hfs acl's goal is compatibility with NT 5.1 acl's ? heh

HFS Plus only supported the standard UNIX file system permissions, however 10.4 introduced support for access control list-based file security, which is designed to be fully compatible with the file permission system used by Microsoft Windows XP and Windows Server 2003.

hmm , am i seeing things ? this paraghaph does not make any sence whatsoever , wikiregulars please take notice and edit--Mancini 18:15, 12 November 2007 (UTC)

Which part are you having trouble understanding? AlistairMcMillan 19:47, 12 November 2007 (UTC)

Apple has made the security permissions compatible with windows, so that it doesn't cause conflicts. Markthemac (talk) 15:25, 22 May 2008 (UTC)

HFS/Finder/Spotlight/Classic "Comments" attribute

The reason I came to this article was to try to find out something about the Comments attribute. Is this not a file system attribute? It isn't really mentioned here, but there are other attributes that also don't get explicit mention here (but may also not be file system attributes). My speculation after reading some things is that the Comments are treated as Finder info and stored by the Finder in the resource fork, either alongside the custom icon (classic comments) or on its own (attached finder comments) or in its own named fork (modern spotlight comments). If that is correct then HFS does not handle these attributes (and probably 'label" as well, though likely the color HFS attribute is really the label attribute). However, I think since attributes and metadata are such a dizzying topic, it might make sense for the article on HFS+ to make some mention that these are not HFS+ attributes (and possibly refer the reader to other articles that discuss their storage).

In summary, it looks to me like HFS Plus stores:

HFS Plus Native Filesystem Attributes/Metadata

attribute	type	note
filename	UTF-16 String	decomposed
color (label)	3-bit flag	1 of 7 possible labels or none
created	date
attributes last modified	date
contents last modified	date
last accessed	date
last backed up	date
locked	boolean
custom icon	boolean
bundle	boolean	directory only (if by "bundle" it means "package")
invisible	boolean
alias	boolean	file only
system	boolean
stationery	boolean	file only
inited	boolean
no INIT resources	boolean
shared	boolean
desktop	boolean

Is this HFS Plus Filesystem Metadata?

attribute	type	note
owner ID	int	is this HFS+ native attribute?
group ID	int	is this HFS+ native attribute?
mode	int	is this HFS+ native attribute?
package flag	boolean	is this HFS+ native attribute? Is this what is called "bundle" in the article?

Non-Filesystem Metadata (forked instead)

attribute	type	fork (in Leopard)	note
comments	UTF-16 String	com.apple.metadata:kMDItemFinderComment	what is the limit? (749 or so?)
mode	int
ACLs	List of access control entries of triplets: 1) ID, 2) authorization, 3) access or deny	This is a hidden fork not displayed through the 'ls' tool

Other Leopard forks

name	attributes	note
com.apple.ResourceFork
com.apple.metadata:kMDItemFinderComment	comment	what is the limit? (749 or so?)
com.apple.FinderInfo
com.apple.diskimages.recentcksum
com.apple.metadata:kMDItemWhereFroms		used to store the source URL for downloads and attachments
com.apple.quarantine		used to provide warnings for downloaded executables
com.apple.TextEncoding	IANA Encoding Name, CFStringEncoding Int	stores the character encoding for plain text files, but not used by all text editors

Much of this could be incorporated into this article. These attributes seem to me to be related to the "Catalog File" and the "Attributes File", but I don't know enough about HFS Plus to say for sure. It also appears that the forks get some form of indexing in the "Attribute File" as well . Some of it could also be spawned into a new article on Mac OS X metadata and filesystem attributes, since these attributes are stored whether the file system supports forks (like HFS Plus) or not (falling-back to ._forkName files instead).

Another issue is that of the convention of using colons for file paths. Where do these colons appear? Is this in the catalog data?

Finally, HFS Plus also provides a place to store hardlink information, that is not discussed at all. This should be discussed as well if anyone can offer some information about that (even if it is handled above the HFS Plus layer, that should be explained). Indexheavy (talk) 20:29, 15 December 2008 (UTC)

Some changes to make it more suitable for a general audience

I've made a few changes to make the article a little more readable for a general audience. I still think more could be done however. The use of acronyms alone in an encyclopedia article are not really appropriate since the general reader has no foundation to decipher the acronym. Even linking to an article alone is insufficient without providing some context for the acronym. Along these lines I changed "NFD" to "Unicode Normalized From D" and although I also introduced "UTF-16", I tried to provide some context around it, indicating that it is a character encoding format. I still think there's a little too much technical information introduced in the opening paragraphs, but it takes a significant amount of time to distill that information into the salient parts and compose supporting subsequent sections that include the more technical details. If I have time I'll take a stab at that, but I welcome anyone else to step in too. I also made some clarifying edits to address the question raised here by Mancini since I definitely can see why a general reader might get confused by the casual mention of Windows in an article about a Mac OS file system. Indexheavy (talk) 18:40, 15 December 2008 (UTC)

I don't see why we are going into such great detail about how names are encoded. I think that needs to be simplified a lot. We want to avoid this article being a magnet for minutiae like File Allocation Table. AlistairMcMillan (talk) 01:08, 16 December 2008 (UTC)

I agree we don't want to get too detailed: especially in the opening paragraphs. The opening paragraphs went way too far into details about the encoding. That's why I moved the discussion of the fact that HFS+ differs from Unicode NFD from the opening paragraphs to an endnote. However, the length of a filename is something of great interest to a general reader of an article on a filesystem and so I think the implications of the encoding should be explained clearly (as I've tried to do). In other words, it isn't necessary to go into great detail about the minutiae of the encoding, but it is necessary to explain the impact of the encoding method to filename length.

Also I do think such discussions of filename length could occur in subsequent sections. When I find sufficient time I'd like to rework the opening to remove some of the minutiae to a section that could include discussion of the filename length (perhaps along with the other filesystem attributes). As for other details on HFS+ in the article, those are certainly welcome, just as long as they're organized into the proper sections. In that way a reader can read as much or as little detail on HFS Plus as they desire. Since a significant role of any file system is the storage of filesystem attributes, I think more details on that would be a good idea, as I outlined below. Indexheavy (talk) 02:20, 16 December 2008 (UTC)

variation of NFD

The article says that HFS+ uses a variation on NFD for normalization, but in following the linked reference, I saw no explanation of this. I'm curious what differences the HFS decomposed normalization has compared to Unicode form NFD. Does anyone know any more details or can quote the specific passage, because I'm not finding it. Indexheavy (talk) 18:30, 15 December 2008 (UTC)

Answering my own question, the differences are discussed here. It mentions there most of the differences occur in Greek character decompositions. More details would require someone examine the differences between the HFS decompositions listed in this table and those of the Unicode normalization form D. Though I'm satisfied with the more precise hyperlink. Indexheavy (talk) 19:53, 19 December 2008 (UTC)

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)

This forum is appropriate for the question, because many encyclopedia readers expect a file system article should address the available undeletion options. Naturally we shouldn't try to answer every user who asks about this in 'talk', rather we should find out, then put that in the article.--AC (talk) 23:22, 20 September 2009 (UTC)

Question about statement regarding "Hard Links"

"Unlike other common file systems HFS Plus supports hard links to directories."

Common file systems include NTFS, which according to [5], DOES support hard links. This statement seems to contain bias. —Preceding unsigned comment added by 207.216.235.159 (talk) 04:15, 11 April 2010 (UTC)

As far as I know, and I could easily be wrong so please feel free to correct me, the only filesystems that support hard links to directories are HFS Plus and NTFS. I've edited the sentence to say "Unlike most other file systems..." instead. AlistairMcMillan (talk) 00:24, 12 April 2010 (UTC)

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)

As of today, both points to the same, so maybe this section can be cleared? DokReggar (talk) 13:54, 10 December 2010 (UTC)

Licensing

I came her curious about why support for this filesystem is limited under Linux. It seems like adding information about the licensing of HFS+ should be added. —Preceding unsigned comment added by 174.16.125.220 (talk) 07:11, 7 March 2011 (UTC)

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)

Removing the part that says that linux journaling support is coming, as the list of accepted GSoC 2011 projects doesn't reflect the referenced project (probably because it wasn't accepted). --Josebita (talk) 01:06, 31 August 2011 (UTC)

Encoding of file names

In the introduction, the article claims that file names are encoded in UTF-16. But Apple writes that the encoding is (decomposed) UTF-8. Who is right? 78.55.119.196 (talk) 19:38, 12 February 2011 (UTC)

I also think the extremely detailed description of the UTF encoding specifics doesn't belong in an article introduction but in a section of its own further down. -- Malvineous (talk) 05:11, 14 June 2012 (UTC)

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)

No new File Manager API was introduced in Mac OS 8.1 to support the new capabilities of HFS Plus. Apple introduced new File Manager API to take advantage of HFS Plus larger file sizes and longer names in Mac OS 9.0. Jumplong (talk) 20:09, 1 September 2015 (UTC)

History

The first paragraph in History says, "However, its first appearance, as a beta filesystem, was in the never-released Copland OS betas."

Where did that information come from? That is just wrong. The white paper (the document that described why Apple needed a new file system to replace HFS) for HFS Plus was finished in Sept 1996 -- that's a month after Copland was canceled. Implementation development was started during the Mac OS 7.6 time frame.

Jumplong (talk) 20:26, 1 September 2015 (UTC)

The 1995 "About the Copland File System" PDF from Apple talks about "an improved version of the HFS volume format". http://www.pagetable.com/?p=211

Amit Singh mentions in his Mac OS X Internals book: "Over the years, some important features that were either created or improved for Copland were added to Mac OS 8 and 9, as was originally intended." and lists HFS Plus as the first example.

These are two sources that pop to mind right now.

Can you point us to sources we can cite that say HFS Plus was developed solely for Mac OS? Can you point us to the white paper you mentioned above? AlistairMcMillan (talk) 23:52, 3 September 2015 (UTC)

I worked on Copland, OS7 and MacOS 8 back in those days, and I recall HFS+ support being added to Copland originally, and that this was part of the functionality that was ported from Copland to MacOS 8, along with chunks of the UI look-and-feel. This is totally WP:OR, of course :) - Alison ^❤ 01:41, 4 September 2015 (UTC)

The "improved version of the HFS volume format" mentioned in the 1995 document "About the Copland File System" was the "Tin Man" file system the Copland file system team designed but never implemented -- it was not HFS Plus. HFS Plus was designed in 1996 by Jim Luther (that is me), Jack Valois, and Don Brady. The engineering work was started by Don, and completed by Don, Deric Horn, Mark Day and myself.

Amit Singh wasn't at Apple so what he says, while published, is hearsay.

The "HFS Plus Revisited" white paper I mentioned was never published outside of Apple. It was an internal document. Because I still work at Apple, I don't know if it would be wise for me to publish it :-)

Don Brady and Deric Horn (who no longer works at Apple) can verify what I've said. They are both easy to contact on twitter, facebook, or linked. Jumplong (talk) 18:56, 16 October 2015 (UTC)

Thanks for replying but I think contacting Don or Deric to confirm this would likely break the original research rule. Anyway someone has removed that line from the article and I don't have any plans to restore it. What you've said here is enough to convince me that you are who you claim to be. Or at least that my sources weren't exactly the most reliable. :) AlistairMcMillan (talk) 20:12, 18 October 2015 (UTC)

"HFS Plus sometimes corrupts files."

If you look at the actual source linked to in the cited ZDNet post about HFS+ corrupting data, you can see at the bottom that the author acknowledges the corruption was hardware caused: "I understand the corruptions were caused by hardware issues. My complain is that the lack of checksums in HFS+ makes it a silent error when a corrupted file is accessed. This not an issue specific to HFS+. Most filesystems do not include checksums either. Sadly…". This problem would have affected NTFS and EXT2/3/4 as well. It's misleading to claim this was the fault of HFS+. --208.117.101.118 (talk) 09:03, 26 October 2015 (UTC)

Updated. Better? AlistairMcMillan (talk) 12:34, 3 November 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to 2 external links on HFS Plus. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20110315014244/http://kerneltrap.org:80/mailarchive/git/2008/1/23/593749/thread to http://kerneltrap.org/mailarchive/git/2008/1/23/593749/thread
• Added archive https://web.archive.org/20110405082701/http://www.google-melange.com:80/gsoc/proposal/review/google/gsoc2011/naota/1 to http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/naota/1

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 16:31, 8 January 2016 (UTC)

HFS Extended

So here is Apple using "HFS Extended" in their own documentation now.

"The kUCCollateTypeHFSExtended ordering scheme sorts maximally decomposed Unicode according to the rules used by the HFS Extended volume format for its catalog. When this order is used, other collation options are ignored; this order is always case-insensitive (for decomposed characters) and ignores the Unicode characters 200C-200F, 202A-202E, 206A-206F, FEFF."

https://developer.apple.com/reference/coreservices/kuccollatetypehfsextended

Guess that makes it official and no longer erroneous. AlistairMcMillan (talk) 12:10, 13 July 2016 (UTC)

They use "HFS Standard" here too now.

The HFS Standard filesystem is no longer supported.

https://developer.apple.com/library/prerelease/content/releasenotes/MacOSX/WhatsNewInOSX/Articles/OSXv10.html

AlistairMcMillan (talk) 12:12, 13 July 2016 (UTC)