View source for Talk:HFS Plus

{{WikiProject banner shell |class=C|vital=yes|1=
{{WikiProject Apple Inc. |importance=High}}
{{WikiProject Computing |importance=Mid |software=y |software-importance=High}}
}}
{{To do}}
{{Archives|auto=yes|search=yes}}
{{User:MiszaBot/config
| algo                = old(365d)
| archive             = Talk:HFS Plus/Archive %(counter)d
| counter             = 1
| maxarchivesize      = 150K
| archiveheader       = {{Automatic archive navigator}}
| minthreadstoarchive = 1
| minthreadsleft      = 4
}}
{{high traffic|date=20 December 2008|url=http://yro.slashdot.org/article.pl?sid=08/12/20/2239255|site=Slashdot}}<!--not main page, but a level-5 comment-->

==Arbitrary section break==
Isn't the official name of the file system HFS+, not HFS Plus? <!-- Template:Unsigned --><span class="autosigned" style="font-size:85%;">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:68.0.211.71|68.0.211.71]] ([[User talk:68.0.211.71#top|talk]] • [[Special:Contributions/68.0.211.71|contribs]]) 01:58, September 21, 2004 (UTC)</span>

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

== Limitations ==

On 4 April [https://en.wikipedia.org/w/index.php?title=HFS_Plus&diff=713490615&oldid=713489189 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 [https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/OSX_Technology_Overview/SystemTechnology/SystemTechnology.html here] and [https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/Filesystem/Filesystem.html here]) and Time Machine makes extensive use of them ([http://pondini.org/TM/Works.html 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 [[Hierarchical File System|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 :)

[[User:EmilJacobs|EmilJacobs]] ([[User talk:EmilJacobs|talk]]) 17:58, 11 May 2016 (UTC)

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

: [[User:EmilJacobs|EmilJacobs]] ([[User talk: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. [[User:Feuermurmel|Feuermurmel]] ([[User talk:Feuermurmel|talk]]) 23:45, 29 January 2017 (UTC)

: Better? Worse? https://en.wikipedia.org/w/index.php?title=HFS_Plus&diff=762762309&oldid=761986422 [[User:AlistairMcMillan|AlistairMcMillan]] ([[User talk: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/

[[User:Kerolasa|Sami Kerola]] ([[User talk:Kerolasa|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....) [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 18:49, 28 January 2021 (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.  <!-- Template:Unsigned IP --><small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/89.239.195.102|89.239.195.102]] ([[User talk:89.239.195.102#top|talk]]) 05:18, 9 June 2022 (UTC)</small> <!--Autosigned by SineBot-->
: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". [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 05:30, 9 June 2022 (UTC)

== "Sequoia" reused for macOS 15 ==

Shouldn't be added to the article, but I think that's pretty interesting, especially considering it doesn't even use HFS+. It uses APFS (like 10.14+). [[Special:Contributions/104.63.56.194|104.63.56.194]] ([[User talk:104.63.56.194|talk]]) 01:50, 14 April 2025 (UTC)
:Companies may use codenames without there being any significance to the reuse.  It's not as if macOS Sequoia was the first version of macOS to default to APFS, nor has Sequoia, as far as I know, dropped support for HFS+ file systems (given that people probably have HFS+ volumes on external hard drives/SSDs, and that some of those may be Time Machine backups, which might not be convertible from HFS+ TM drives to APFS TM drives, there may be an incentive for Apple to continue to support HFS+).
:It's of some interest, but I don't know that it's of significant interest. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 05:59, 14 April 2025 (UTC)