macOS Sierra Tidbits: Apple File System, RAID Support, and More

[cult hero]

Just read the Apple File System Guide and I think it's the most exciting feature of the new macOS. Wonder why they didn't mention it in detail at WWDC, probably don't want the FBI to freak out again.

The new security features are very welcome.... I'll do anything to keep my pretty pictures private.

It's because of the audience at the keynote, and I'm not talking about the people physically in attendance. Apple live streams this because thousands of people view it and most of those thousands are not developers. There's media and plenty of others who do not know or care about a filesystem. The keynote itself shows off things that the end users will either use, understand, or appreciate.

A filesystem? My dad doesn't know what RAID is. He cares that his hard drive is "encrypted," not whether it's FileVault or something else. This new filesystem has huge implications for Time Machine, but... from his perspective, it'll just keep on chugging away. End users may ultimately care about the end results of a filesystem (I imagine at the next OS keynote they're going to tell us that Time Machine is 10x faster or something) but they don't care about the filesystem itself.

Consider the audience. People who freak out and act like the keynote is the be all, end all of features are just looking for reasons to whine.

 

[Zarniwoop]

That article doesn't tell the average user what is wrong with HFS+. It is written in technical jargon. Is there one that explains in simpler language what its drawbacks are?

Linus reffered to this: HFS+/ OS X pretends to be using case-sensitive file names. That means there are CAPITAL letters and small ones. But in reality in the filesystem, they are all written in small, case-insensitive way. So save a file "London.doc" and you can copy it from the filesystem also typing "london.doc" or "lONdon.doc".. it doesn't make a difference. This breaks the compatibility with UNIX and network shares, which are really case-sensitive. So Apple has to translate the filesystem to network clients, servers and even for itself. It's a mess. Something similar that happened between FAT16 and FAT32.

It is possible to turn on the case-sensitive mode for HFS+.. but then apps start to crash and system becomes unstable. Apple doesn't recommend or support this officially.

 

[deputy_doofy]

**** that.

No option to install apps from "anywhere"? Mandatory binary code signing? No thanks.

-SC

The "anywhere" option simply didn't warn you that it was unsigned. Relax. You can still install from anywhere.

 

[blacka4]

Great, so now my 2TB media drive is going to disappear because I watched most of the movies in itunes? crap I hope not.

 

[forerunnerg34]

As much as the intentions of this new file system is to make things easier / more secure .. If Apple half bakes this like it has many other things lately, it could be a disaster. BUT .... I feel like they're going to give this a lot of attention if ALL their devices are going to be running it. Let's hope it's beneficial.

You are right, a new file system is something not easy to do and requires advanced software engineering, something Apple has demostrated is not very good at anymore. I mean I can survive having to restore my iPhone or iPad from an update that bricked it, But a bricked Mac.. all that data, applications, even if you have backups, the cost would be hight based on the time you would need to format your Mac and restore your fles. I think I will wait until the third update after the official release, I even have a sticky note: "DO NOT UPDATE ANY APPLE SOFWARE ON DAY ONE".

 

[Amazing Iceman]

I can imagine the panic regarding apps from 'anywhere' but I have seen a couple of vendors including in their installation instructions the steps to disable Gatekeeper, which obviously leaves naive users vulnerable after that. Removing the permanent options seems sensible to thwart that.

This will force Developers to get their apps signed by Apple, which is a free and painless process. Xcode 8 takes care of the signing. This is mainly to help prevent malware from installing by mistake on macOS.

 

[ignatius345]

Personally I would like an iCloud solution that synced all my files AND applications across machines so I could work on a lightweight MacBook on the go, but switch back to a monster iMac at work and for everything to be 100% in sync, that'd be pretty nice.

Dropbox with selective sync can do some of this today -- minus the "applications" part. I also understand they're working on an "on demand" feature that will show small placeholder files that get downloaded when you click on them. Interested to see how this evolves because I've generally found Dropbox's approach to be a lot more user-friendly than iCloud's, and better for collaboration.

 

[leman]

Linus reffered to this: HFS+/ OS X pretends to be using case-sensitive file names. That means there are CAPITAL letters and small ones. But in reality in the filesystem, they are all written in small, case-insensitive way. So save a file "London.doc" and you can copy it from the filesystem also typing "london.doc" or "lONdon.doc".. it doesn't make a difference. This breaks the compatibility with UNIX and network shares, which are really case-sensitive. So Apple has to translate the filesystem to network clients, servers and even for itself. It's a mess. Something similar that happened between FAT16 and FAT32.

I haven't yet run in a single case where this would cause practical problems with UNIX compatibility. I also haven't seen a single practical case where case-sensitivity would be important for either Linux or UNIX.

 

[PatriotInvasion]

There should be new iCloud storage tiers to accompany some of these changes. While I find $2.99/month for 200GB to be reasonable, not having anything in between this and the $9.99 1TB tier seems wrong. There should be a $4.99/month 500GB plan.

 

[31 Flavas]

I really dislike this, but I am not too worried about it. This is just the first developer preview version. Apple has removed and added back options and settings before during preview and beta periods. If enough of us ask for the "anywhere" setting to be returned, they will probably do it. If not, I'm sure it just controls a value set in somewhere that can be changed with a terminal command.

Let me just play devil's argument here -- If you have an unsigned binary and wish to run it, as the section you quoted points out, you right click or control click to open the file. Gatekeeper, will tell you the binary is unsigned and should not be trusted, however, you'll have the "proceed anyway" option.

Therefore, what is the argument (or your argument) for allowing Gatekeeper to be entirely disabled? Convenience?

On page 5, I read a post which pointed out that by removing the option to disable Gatekeeper it guarantees that for binaries *which are signed* are the orginals. That is if the binaries are tampered with or adulterated in an attempt to introduce malicious or spy software code (or for software piracy) Gatekeeper will be able to notice that and prevent the binary from being executed.

Now that doesn't guarantee that a signed binary isn't malicious or spy software itself -- but, it guarantees the binary hasn't been tampered with and, as the poster stated, eliminates software piracy. To that end I would not support having an "anywhere" setting as a "preference" / "convenience" option.

 

[guerro]

But I need new, more powerful hardware to run this new OS. But Apple haven't released new, more powerful hardware in 3 years. This is what is pissing off Mac users.

 

[Zarniwoop]

I haven't yet run in a single case where this would cause practical problems with UNIX compatibility. I also haven't seen a single practical case where case-sensitivity would be important for either Linux or UNIX.

That is normal for an end user. Because it's developers pain in the rear end. Anyway, Mac's way is easier for the user to handle, but it breaks the standard between systems.

It's MUCH more work for a filesystem to be case-insensitive than -sensitive. A filesystem is case-sensitive by default, in the simplest case; it can only be made case-INsensitive through a lot of extra engineering. In UNIX, all the system has to do is sort on the ASCII values of the first letters of the filenames. In the Mac OS and Windows, the filesystem has to be smart enough to create synonyms of various letters — A for a, and so on — and sort accordingly. That takes a LOT of code. It's a testament to the completeness of the original Mac OS that in 1984 this was all handled properly, before Windows even brought lower-case letters to the PC side.

It goes well beyond that, too. Look at how the Mac handles foreign, extended characters. Rather than the Windows way, in which you have to pick accented characters from a bizarre grid of upper-ASCII values, the Mac builds such things into the keyboard input routines in a way that's workflow-consistent. Press Option+U, and you get an umlaut. Then enter a vowel, and the umlaut combines with the vowel. Option+U,U — and there's your ü.

And what about sorting? The Mac sorts ü right along with the other U variants. iTunes recognizes Bjork and Björk as the same artist.
- Brian Tiemann

 

[leman]

That is normal for an end user. Because it's developers pain in the rear end.

I am a developer. I don't really understand what you want to say with the quote in your post. Yes, OS X correctly handles Unicode comparisons and has a superior input capabilities to many other platforms. What relation does this have with case-sensitive vs. case-insensitive filesystems? In fact, these are orthogonal questions: a FS can be case-insensitive without being unicode (or any encoding) aware. Not to mention that the quote is not entirely accurate. Within ASCII, translation to lower-case is trivial. A case-insensitive FS would just mean storing everything either with lower or upper case and transforming all identifiers accordingly. Now, unicode-aware FS, that is something much more complex. I am not even sure if HFS+ is entirely unicode-aware.

 

[PizzaBoxStyle]

Anywhere" Dropped From Gatekeeper

Apple has removed the Gatekeeper option to allow apps to be downloaded from "anywhere" by default in System Preferences > Security & Privacy, resulting in a warning dialog when you attempt to open an app from an unidentified developer. "Mac App Store" and "Mac App Store and identified developers" remain selectable.

Well, it looks like we are going to have to rely on the web to become our one true our open application platform.

The web stack still can't do everything a native stack can, but it can do a lot.

 

[tampageek]

You're right. Hope for Apple to return to glory has become torture. It really is time to give up on Apple. ;(

When Apple announced that Mac and iPad sales were down, they also said their services revenue was up. IMHO they are moving more toward being subscription based /cloud company i.e. Microsoft. So Apple takes the ports off their machines, auto loads your files to the cloud, locks down the OS and starts charging for access to your data.

This is very similar to the direction of Microsoft. It may be only a matter of time before Apple goes with forced updates as well. Just sayin.....

 

[azpc]

Glad to see that a new file system is coming. I am also glad that Notes can have a default font size.

Here are other improvements that I would like to see:

https://forums.macrumors.com/threads/needed-improvements.1977518/

 

[Terminated]

Mr. Torvalds can explain you why there's a need for a new FS:
http://www.cio.com/article/2868393/...s-is-probably-the-worst-file-system-ever.html

None of those particular issues he complains about (case-insensitivity and NFD normalisation), would require a completely redesigned file system. There is already a case-sensitive HFS+ variant, and you could as easily specify another variant that either requires a different Unicode normalisation flavour or simply doesn't care about normalisation.

In my opinion, legitimate reasons to design a new file system include improving robustness, usability, speed and space efficiency. The character encoding used for file names is just a convention that can easily be changed without altering too much the overall design.

Some developers have a strong opinion on whether file systems should be case-sensitive or not, often because they are used to one or another. In practice, both can cause trouble, or rather what causes trouble is the existence of both. If you use a case-insensitive file system, you'll have trouble with programs that assume case-sensitiveness, but there are also programs that assume case-insensitiveness, and these will have trouble with case-sensitive file systems.

 

[oneMadRssn]

Let me just play devil's argument here -- If you have an unsigned binary and wish to run it, as the section you quoted points out, you right click or control click to open the file. Gatekeeper, will tell you the binary is unsigned and should not be trusted, however, you'll have the "proceed anyway" option.

Therefore, what is the argument (or your argument) for allowing Gatekeeper to be entirely disabled? Convenience?

On page 5, I read a post which pointed out that by removing the option to disable Gatekeeper it guarantees that for binaries *which are signed* are the orginals. That is if the binaries are tampered with or adulterated in an attempt to introduce malicious or spy software code (or for software piracy) Gatekeeper will be able to notice that and prevent the binary from being executed.

Now that doesn't guarantee that a signed binary isn't malicious or spy software itself -- but, it guarantees the binary hasn't been tampered with and, as the poster stated, eliminates software piracy. To that end I would not support having an "anywhere" setting as a "preference" / "convenience" option.

If I can just right click or command click on the unsigned/tempered binary to run it, then removing the "anywhere" option really doesn't do anything to address piracy at all. So that is a moot point that doesn't cut one way or the other at all.

As for why I want the "anywhere" option to remain, it is because the other ways to circumvent gatekeeper have not always worked well. Sometimes an installer is just a wrapper that contains another binary or set of scripts. If I right click or command click to run the installer, the binary within is still sometimes blocked. It's nice to have a setting that just turns this feature off entirely. I can then turn it back on when I done messing with whatever it is I am messing with. An example of this I dealt with recently is the PIA client installer.

The uses for this aren't just piracy. There are many developers that choose not to pay the Apple developer fee. Sometimes their stuff is open source, sometimes it is just freeware, and sometimes it's just old and hasn't been updated in a long time but still useful, but either way, users shouldn't have to jump through hoops to use their software. Another huge example is running X11 to run Linux binaries on OS X. Gatekeeper makes this a pain in some situations. It's best to just turn the setting to "anywhere" for the duration of the time you need to do that, rather than worry right clicking or whatever on a per binary basis.

So my reason is not "convenience" alone. It is convenience and necessity. Also, a big one is that it's my computer and I won't tolerate Apple telling me what I can and can't do. I'm not saying gatekeeper is bad - it's great 98% of the time. So is my firewall. But with some regularity comes a situation where I just want to turn one or the other off for a period of time.

Overall, I wonder who benefits most form removing the "anywhere" setting. It's not set to that by default, and you even have to enter an admin password to change the setting. I would argue only the truly advanced user ever dig deep enough to find it and know what it is. So who wants it removed? Apple stands to gain by forcing developers that don't pay for a dev account to do so, and competitors that sell paid apps in the app store stand to gain by making it more difficult for open source and freeware apps to exist. So this is really the typical case of the big guys trying to muscle out the little guys under the veil of security?

 

[Zarniwoop]

None of those particular issues he complains about (case-insensitivity and NFD normalisation), would require a completely redesigned file system. There is already a case-sensitive HFS+ variant, and you could as easily specify another variant that either requires a different Unicode normalisation flavour or simply doesn't care about normalisation.

In my opinion, legitimate reasons to design a new file system include improving robustness, usability, speed and space efficiency. The character encoding used for file names is just a convention that can easily be changed without altering too much the overall design.

Some developers have a strong opinion on whether file systems should be case-sensitive or not, often because they are used to one or another. In practice, both can cause trouble, or rather what causes trouble is the existence of both. If you use a case-insensitive file system, you'll have trouble with programs that assume case-sensitiveness, but there are also programs that assume case-insensitiveness, and these will have trouble with case-sensitive file systems.

Yes, Apple could turn on the case-sensitive HFS+, but it would break up too many things. So, changing FS totally will force the developers to change their habits. And yes, APFS has many interesting new things, case-sensitiveness is not on the list. Those great new features are the carrot, and we might get the case-sensitive system as a side order.

The principle problem with case-INsensitive is, that Apple claims, that OS X is Unix compatible - even Posix certified. And then it uses case-INsensitive file-system, creating potential situations, that things don't go as planned. Especially with languages that have accents.

 

[manu chao]

Hmmm, I assume there will be an easy way to disable these "optimized storage" functions. I don't want stuff being uploaded to the cloud and removed from local copy on the OS's whims really.

Why would it be any different than iCloud Photo Library and Apple Music, where (a) uploading files (aka using it) is optional and (b) the 'optimised storage' is optional even after that?

 

[Mebsat]

I hope for your sake that you're being ironic. If you really think they would implement it like that, I don't know what to tell you

It's still a valid question to ask how well Apple's deduplication will work in the cloud and where it came from. Licensed or built in house?

I highly doubt they are going to store everything that gets uploaded. If they are basically replicating Dropbox and giving people permission to download a frequently stored file, I for one am extremely nervous to see how that works out. This level of software engineering has not been their strong suit for a while now.

 

[MarsViolet]

Remember when the MacOS was simple and intuitive?

That ended with System 7 when things got weird with aliases and Publish and Subscribe, the Control Panel became a folder, and Apple sent fonts into chaos by introducing TrueType.

 

[SteveJobzniak]

If I can just right click or command click on the unsigned/tempered binary to run it, then removing the "anywhere" option really doesn't do anything to address piracy at all. So that is a moot point that doesn't cut one way or the other at all.

Right-clicking a tampered/modified/cracked binary and choosing "Open" will give you the "This application is damaged and can't be opened. You should move it to the Trash." error message. There is no way to open cracked programs anymore.

The right-click method only opens totally unsigned binaries, i.e. open source and freeware that hasn't bothered to get a free developer signature.

In short: Removing "Anywhere" kills piracy and prevents malware infected binaries from running. It doesn't affect UNSIGNED open source/freeware, which can still be opened via a right-click the first time you run it (after that it remembers that you want to allow it).

However, I discovered that you can (at least currently) disable Gatekeeper via a Terminal command. I hope they lock down that loophole too or all of this is easily defeated by the pirates.

Yes, Apple could turn on the case-sensitive HFS+, but it would break up too many things. So, changing FS totally will force the developers to change their habits. And yes, APFS has many interesting new things, case-sensitiveness is not on the list. Those great new features are the carrot, and we might get the case-sensitive system as a side order.

The principle problem with case-INsensitive is, that Apple claims, that OS X is Unix compatible - even Posix certified. And then it uses case-INsensitive file-system, creating potential situations, that things don't go as planned. Especially with languages that have accents.

I for one want macOS to be case-sensitive. It's better for performance. Comparing "abc" to "ABC" and seeing that it's a mismatch takes a single instruction: The character code for a is not A. To do the same on a case-insensitive system requires comparing every letter using some transformation function that translates each letter. It's just stupid.

There's only one argument for case-insensitive: A handful of Mac apps, such as Adobe's, break since their code may do something like "open the file called Hello.gif" but it's actually called "hello.gif" on disk. That's developer stupidity and can be fixed with time, and is rare. I think Adobe is the only company whose software has trouble when macOS is installed on a "HFS+ Case-sensitive" partition.

 

[Terminated]

It might be good for the english speakers, but for the rest of 95% of the planet it causes problems.

The problem is, that Apple claims, that it is Unix compatible - even Posix certified. And then it uses case-INsensitive file-system, creating potential situations, that things don't go as planned. Especially with languages that have accents.

My native language is not English and it has accents. I'm not saying that it's good or bad, I'm only saying that you don't need a completely new file system design to deal just with this problem. I'm also saying that case-sensitive file systems potentially create as many problems, depending on what you need to be compatible with.

 

[Galas]

Mr. Torvalds can explain you why there's a need for a new FS:
http://www.cio.com/article/2868393/...s-is-probably-the-worst-file-system-ever.html

Logged in just to post this.