Talk:HFS Plus

Arbitrary section break

Isn't the official name of the file system HFS+, not HFS Plus? — Preceding unsigned comment added by 68.0.211.71 (talk • contribs) 01:58, September 21, 2004 (UTC)

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

Limitations

On 4 April some bulletpoints were added to this heading, which all go unreferenced. Especially "real hardlinks" raises an eyebrow, as Apple developer documentation makes references to them (for example here and here) and Time Machine makes extensive use of them (as Pondini, a helpful site about this subject and more, explains).

Now, I'm also wondering about concurrent access. This was listed as a limitation of HFS (the predecessor of HFS+) on this wiki page, which had to do with how the catalog file was built. I find no other credible sources making this claim.

The other bullet points are more obvious and well known, but would of course also be stronger if citation was given :)

EmilJacobs (talk) 17:58, 11 May 2016 (UTC)

I've added a "citation needed" to the two most troublesome claims.

EmilJacobs (talk) 16:56, 12 May 2016 (UTC)

What the hell is a "real hard link"? The reference provided just talks about how hard links are implemented in HFS+ (which is arguably a workaround). According to TN1150, hard links on HFS+ should behave exactly as they do on any other UNIX. I suggest removing that bullet from the list. Feuermurmel (talk) 23:45, 29 January 2017 (UTC)

Better? Worse? https://en.wikipedia.org/w/index.php?title=HFS_Plus&diff=762762309&oldid=761986422 AlistairMcMillan (talk) 16:22, 30 January 2017 (UTC)

It might be worthwhile to mention : (colon) as used as a HFS+ directory marker, and this causes still problems. For example golang zip archives cannot store files with colon in filename because of HFS+. This issue is documented in USENIX 2000 talk The Challenges of Integrating the Unix and Mac OS Environments http://www.wsanchez.net/papers/USENIX_2000/

Sami Kerola (talk) 10:38, 28 January 2021 (UTC)

That's an operating system limitation, not a file system limitation. Code using UN*X APIs can store files with a colon in the file name, regardless of whether they're writing to an HFS+ file or not; as Wilfredo notes:

This was easy to address, though it involves transforming strings back and forth. The HFS+ implementation in the kernel's VFS layer converts colon to slash and vice versa when reading from and writing to the on-disk format. So on disk the separator is a colon, but at the VFS layer (and therefore anything above it and the kernel, such as libc) it's a slash.

That code cannot, of course, store files with a forward slash in the file name, but You Just Can't Do That On A UN*X, no matter what file system you're using - it's as much of a limitation on, for example, Linux with an efs2 file system, or Good Old Fashioned V7 UNIX with the V7 file system.

Code running on the classic Mac OS, and code running on Mac OS X/OS X/macOS using APIs that expect classic Mac OS-style paths, will take the classic Mac OS-style path, replace colons with forward slashes forward slashes with colons, and hand the resulting path to UN*X APIs. As Wilfredo says:

However, the traditional Mac OS toolkits expect colons, so above the BSD layer, the core Carbon toolkit does yet another translation. The result is that Carbon applications see colons, and everyone else sees slashes.

That was true regardless of whether the underlying file system was HFS+ or not - if the underlying file system is, say, NTFS, with the file system being mounted over SMB using smbfs, or ext2, with the file system mounted from a Linux NFS server using nfs, that would also apply.

If that's a problem for golang archives, it means somebody outside of Apple isn't doing the right thing. (Dear Google: stop treating macOS as being that different from other UN*Xes. Your Google Earth installer for macOS, for example, should not assume case-insensitivity! That doesn't work if the user's home directory is mounted from an NFS server with a case-sensitive file system; I filed a bug on that many years ago when it did fail on my home directory mounted from such a server - a server that happened to be running Mac OS X....) Guy Harris (talk) 18:49, 28 January 2021 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on HFS Plus. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added {{dead link}} tag to https://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git%3Ba%3Dtree%3Bf%3Dfs%2Fhfsplus%3Bhb%3DHEAD
• Added {{dead link}} tag to https://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git%3Ba%3Dcommitdiff%3Bh%3D5c36fe3d87b3f0c85894a49193c66096a3d6b26f
• Added archive https://archive.is/20120722061818/http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/filesystems/hfsplus.txt;hb=60fd4d6a1953accd3d57f8e4f3b0f4692598bf4e to https://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%3Ba%3Dblob_plain%3Bf%3DDocumentation%2Ffilesystems%2Fhfsplus.txt%3Bhb%3D60fd4d6a1953accd3d57f8e4f3b0f4692598bf4e

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

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.—InternetArchiveBot (Report bug) 02:11, 9 September 2017 (UTC)

Doubting -most- other file systems do not support hard links.

I added a dubious tag to the claim that most filesystems beside HFS+ does not support hard links. Besides the FAT systems and some ancient ones that are no longer used (I have no idea how many that amount to), I don't know of any formats that does not support hard links. The claim is unsupported by any sources and I doubt any will ever be made. — Preceding unsigned comment added by 89.239.195.102 (talk) 05:18, 9 June 2022 (UTC)

That's not the claim being made; the claim is that, unlike most file systems, HFS+ supports hard links to directories'. No claim is made about supporting hard links to plain files.

I changed it to say that, unlike most file systems that support hard links, HFS+ supports hard links to directories. Hopefully that makes it clearer what the claim is.

Note that this is a consequence of the code that implements the file system; the support for hard links to directories was added for Time Machine - Time Machine backups to HFS+ all have complete file system directory trees, not just partial trees of files modified since the last backup, but save space by hard-linking to unchanged files and unchanged directories, where "unchanged", for directories, means "the directory has the exact same set of files and subdirectories and all of those files and directories are unchanged as well". Guy Harris (talk) 05:30, 9 June 2022 (UTC)