Live data from Hacker News

Apple File System

developer.apple.com

101–110 of 406 posts

Re: Apple File System

#101

Earlier quoted context omitted.

That's what people were hoping for with ReFS from Microsoft, which released years ago, but that still hasn't happened yet.

btrfs was available in the Linux kernel in 2009, but didn't see production release in the tinkerer-friendly distros until 2012 and in an enterprise distro until 2015. These things take time: filesystems need to be absolutely bulletproof, especially in the consumer space where (unlike Linux) most users will have no idea what to do if something goes wrong. I'd say Microsoft is still on schedule.

Speaking of which, is there any other good FS to use for desktop Linux (on an SSD on ArchLinux) or is Ext4 still the recommended standard?

Re: Apple File System

#102

No snapshotting yet, can't boot, no migration tools for existing setups (time machine, filevault, fusion). It'd be interesting to see whether their permission changes introduced in 10.11 will travel further down the fs. Also, I don't see any mention of compression like lz4. Lots of work until release in 2017!

Is compression really that big a deal any more?

Re: Apple File System

#103
post #74

I'm going to be very cynical and say that based on their track record of major OS overhauls I am _not_ looking forward to the bugs and issues that will sneak past their QA. I still have nightmares of all the bugs with their wifi & USB stack changes in the last couple OSX releases. Please Apple, for your own good don't 'move fast and break things' with the filesystem. At the very least it's time for everyone to make s…

Compared to how risky and problematic HFS+ is? It may still be better.

Re: Apple File System

#104
post #60

Earlier quoted context omitted.

Presumably as with today, you'll have the option. I don't have a strong opinion on case sensitivity of file names, but I suspect they'll keep it case insensitive by default. I think for the average non-technical user that two files, "MyFile.txt" and "myfile.txt", being different could lead to some confusion, and Apple historically has apparently considered that confusion unacceptable.

For the end-user they could prevent duplicate different-cased file names in the UI layer (the Finder), instead of the file system. That would be a more appropriate place for it anyway.

That would likely be a hassle because you'd have to be consistent for all programs that ever save or read a file. As a result it has to be an OS-level thing at least, if not at the file system level. I don't have a huge preference (case sensitive or insensitive), I think it's not worth a religious war, but whatever the choice is, it should be completely transparent to understand what convention the system is using as a coder, and as a general user.

Re: Apple File System

#105
post #55

Earlier quoted context omitted.

It's not HFS. That in itself is a pretty huge advantage.

That's not really a useful statement. HFS+ has worked pretty well for many years and is really well tested. This will be a completely new filesystem, which means it will have lots of new code that can have bugs or incompatibilities with current apps. APFS sounds like it's going to be great, but I think not being HFS is a disadvantage rather than an advantage.

> HFS+ has worked pretty well for many years and is really well tested

Nope. HFS+ is REALLY GOOD at losing data or having silent corruption. I'm thrilled to have a new filesystem just because it's not HFS based.

I'd celebrate having NTFS as the official filesystem. It's much more modern than HFS+.

Re: Apple File System

#106
post #2

Siracusa will finally be happy. ;-) Sounds an awful like like ZFS (zero-cost clones, read-only snapshots) but could it be? I would imagine they'd start from scratch to due IP issues. Clearly this is immature technology they want to get out for testing/evaluation before it's fully adopted even into their own products. (See below.) - - - from the release notes - - - As a developer preview of this technology, there are…

"FileVault: APFS volumes cannot currently be encrypted using FileVault. " This one is confusing, because this is a logical volume feature. Not sure how or why APFS would ever care that some layer above it is encrypting stuff.

On the one hand, that may be an artificial limitation. If this turns out to have some bug that overwrites the encryption keys, they could of course say "we warned you", but it would not be good PR. Also, if beta developers report intermittent smaller data-losing bugs, they might want to study the affected drives to see what went wrong with it. Not having encryption enabled on them will make that a tiny bit easier.

On the other hand, if the new ability to partition drives with flexible partition sizes includes separate encryption keys per partition, and encryption/decryption is done by the block driver, they may have work to do to keep that block driver informed about what blocks should get encrypted with what key.

Re: Apple File System

#107
post #16

Earlier quoted context omitted.

Sure, this is a developer preview. Final release in 2017 will surely make this FS the default.

That's what people were hoping for with ReFS from Microsoft, which released years ago, but that still hasn't happened yet.

Apple has (relatively, you can replace some harddrives) the most control on hardware, so at least from that perspective it's easier for them.

Re: Apple File System

#108
post #102

No snapshotting yet, can't boot, no migration tools for existing setups (time machine, filevault, fusion). It'd be interesting to see whether their permission changes introduced in 10.11 will travel further down the fs. Also, I don't see any mention of compression like lz4. Lots of work until release in 2017!

Is compression really that big a deal any more?

I heard there was this Pied Piper startup, it's making big waves in compression technology ;)

Re: Apple File System

#109
post #91

Earlier quoted context omitted.

More problematic is that many case insensitive hard drives would be copied into new machines and there would be millions of conflicts. Some utility would have to sit there and annoy people by asking them to make decisions.

I can see why there would be conflicts going case sensitive -> case insensitive, but I can't see why there would be conflicts going the other way. Am I missing something?

I think you have it backwards. If you try to expand an archive with FOO.TXT and foo.txt, what should happen if you're writing to a case insensitive file system?

    $ touch HI
    $ touch hi
    $ ls
    HI
So that's disturbing. Another problem is every software you can think of will be comparing two files case insensitively. Almost weekly I get burned by this.

    $ touch HI
    $ test -f hi && echo ok
    ok

Re: Apple File System

#110

Earlier quoted context omitted.

The keynote was for consumers and the press. The 2 PM PT Platforms State of the Union is for developers and will likely go into this more, and if not there is a session tomorrow specifically about it.

Still... Marketing fully-encrypted snapshot-featured filesystem with focus on SSD / Flash, would make much more impact than having "native-tabs" for apps on an event like that. Anyway I'm not a specialist, just another IT guy, so maybe I'm too opinionated to argue more.

I don't think this is going to be a part of macOS Sierra as a standard feature, given that it has a release date in 2017 while Sierra will be out later this year. So it makes sense to not include it in a Sierra announcement.
Post reply on HN