File systems seem to be a particular weakness of Apple. HFS+ is pretty terrible. APFS is better, until something goes wrong and then it's just as terrible. Add "network" and the situation is 10x worse. I recently gave up on Time Machine (via Samba) entirely because it would regularly corrupt itself and destroy all my existing backups.
Something is deeply broken with Samba in macOS, all Samba versions and all macOS versions.
It just never works. And just when you think it's finally reliable and has worked for a while, it breaks in new unexpected ways. Sometimes hanging the whole machine. This was with both macOS as a server and a Linux server (less issues with Linux, but still broken).
Samba isn't great on other OSs either, but not as broken as on macOS. At this point I've given up on Samba completely, and consider it something I won't use again.
But a few weeks before release, Sun was acquired by Oracle.
It was going to take months of further negotiations to nail it down. Apple-sourced ZFS on macOS was canceled.
ZFS had been released by Sun before the Oracle Situation under their MIT-like CDDL.
I suppose when Big Tech is involved, they rattle patents at one another until the dust settles with handshakes and payouts all around. I'm speculating here. But I was told that the CDDL was not considered sufficient for Apple to support its own development efforts.
ZFS is relatively complicated, but it generally works. At the time, Apple was shipping servers with iSCSI SAN and a GUI comparable to Disk Utility.
Really a shame. I was running native ZFS on my Mac Pro that summer. Eventually migrated those pools to Open Solaris and eventually to Linux.
Hard agree. Apple has lost my data on multiple occasions. I resized my Time Machine partition and that silently corrupted most of my backups.
Apple is the only company that makes such terrible file systems. I have resized partitions on NTFS and EXT3 and never lost any data. Apple is uniquely terrible in terms of file systems and data integrity in general.
> The disk which I have such problems with is a little unusual in that it’s partitioned into two: a small HFS+ volume, and a much larger APFS container.
So is this the actual bug then? Because I just used Disk Utility (in Tahoe) to check and repair an AFPS volume and it appeared to do the right thing, with the caveat that I had to "eject" it manually since Disk Utility complained that stuff was using it. Presumably, booting into macOS Recovery would've worked, too.
If the author's reading, is there a way we can help amplify any existing bug report(s)?
The year is useful in the title when the article provides out of date information. This isn't the case here and adding a ' (2021)' would have made the title less informative because people would assume the problem would have been fixed by now.
> The year is useful in the title when the article provides out of date information.
No, that's not the reason for the HN convention. Why would someone even submit an article with out of date information?
The reason for the convention is that "news" is generally expected to be new, so when it's not new, HN readers want to be informed of that fact, and they can react to the submission accordingly. It's a simple courtesy to readers.
History is not the same as out-of-date information.
The submitted article is not an historical review. If there was an article written explaining how Disk Utility had a bug, but the bug is now fixed, that might be interesting. On the other hand, to submit an article about a bug that no longer exists, with no explanation, would simply be misleading, out-of-date information. In this case, however, the bug still exists presently, so it's not history either.
A few years back I found a bug that would make deleted photos show up in the Photos app on iPhone simply by putting transparent PNGs into the photo library. I reported it to Apple via web, no response. I called their support and talked to a very nice guy who had an in-depth conversation with me about it and even watched a video I made showing the bug. He said he was taking the issue "up the chain." About 6 months and two .x.x releases later and the bug still existed. I reported it again, no response.
So I emailed AppleInsider who did a short article about it and within two weeks another .x.x release came out and the bug was fixed.
Sadly I think this is one of the only ways to get big tech companies to take action these days. Cant tell you how many times I have read about Comcast, Verizon, etc screwing someone over and being unreasonable about it until theres an article on ArsTechnica or some similar site about it.
These companies don't care about having reliable products, they care about the average consumer having the perception that their products are reliable.
This is the reason security researchers started demanding deadlines before publishing their findings publicly. Forcing them to do damage control by publishing their dirty laundry turned out to be the best way to motivate companies to listen to reports.
Apple basically stopped working on non-BS macos features 10-15 years ago. The FDE unlock on boot ssh was literally shocking for this reason. Apple’s software priority is iOS DAU.
I needed to resize my APFS partition to install Asahi Linux.
The Asahi installer couldn't resize the partition due to some orphan inodes or something.
Rebooting into Recovery mode and using Disk Utility (GUI) and diskutil (CLI) didn't fix the issues.
But `fsck_apfs -y` did the trick. I had to first do `diskutil unlock volume -nomount` as it was an encrypted volume.
Where were you two weeks ago! Gonna try it
Rather, where were they three years ago?
fsck* is on the floss side, is it not?
No. fsck_apfs is an Apple tool.
File systems seem to be a particular weakness of Apple. HFS+ is pretty terrible. APFS is better, until something goes wrong and then it's just as terrible. Add "network" and the situation is 10x worse. I recently gave up on Time Machine (via Samba) entirely because it would regularly corrupt itself and destroy all my existing backups.
Something is deeply broken with Samba in macOS, all Samba versions and all macOS versions.
It just never works. And just when you think it's finally reliable and has worked for a while, it breaks in new unexpected ways. Sometimes hanging the whole machine. This was with both macOS as a server and a Linux server (less issues with Linux, but still broken).
Samba isn't great on other OSs either, but not as broken as on macOS. At this point I've given up on Samba completely, and consider it something I won't use again.
macOS Snow Leopard almost adopted ZFS.
But a few weeks before release, Sun was acquired by Oracle.
It was going to take months of further negotiations to nail it down. Apple-sourced ZFS on macOS was canceled.
ZFS had been released by Sun before the Oracle Situation under their MIT-like CDDL.
I suppose when Big Tech is involved, they rattle patents at one another until the dust settles with handshakes and payouts all around. I'm speculating here. But I was told that the CDDL was not considered sufficient for Apple to support its own development efforts.
ZFS is relatively complicated, but it generally works. At the time, Apple was shipping servers with iSCSI SAN and a GUI comparable to Disk Utility.
Really a shame. I was running native ZFS on my Mac Pro that summer. Eventually migrated those pools to Open Solaris and eventually to Linux.
Hard agree. Apple has lost my data on multiple occasions. I resized my Time Machine partition and that silently corrupted most of my backups.
Apple is the only company that makes such terrible file systems. I have resized partitions on NTFS and EXT3 and never lost any data. Apple is uniquely terrible in terms of file systems and data integrity in general.
Why Samba? That is not used unless you must support windows. NFS would probably better option for Linux, *inx and Mac.
Samba is used for Windows support.
> The disk which I have such problems with is a little unusual in that it’s partitioned into two: a small HFS+ volume, and a much larger APFS container.
So is this the actual bug then? Because I just used Disk Utility (in Tahoe) to check and repair an AFPS volume and it appeared to do the right thing, with the caveat that I had to "eject" it manually since Disk Utility complained that stuff was using it. Presumably, booting into macOS Recovery would've worked, too.
If the author's reading, is there a way we can help amplify any existing bug report(s)?
When using Apple hardware, don't expect things to work if they're not relevant to 95% of their customers.
Why post this with invalid title? It should be in 2021 it was impossible…
It's still impossible. See my other comment:
(EDIT: corrected link to comment)
https://news.ycombinator.com/item?id=45322650
By HN convention, the submission title should still have (2021) appended.
The year is useful in the title when the article provides out of date information. This isn't the case here and adding a ' (2021)' would have made the title less informative because people would assume the problem would have been fixed by now.
There was no good reason to add the year.
> The year is useful in the title when the article provides out of date information.
No, that's not the reason for the HN convention. Why would someone even submit an article with out of date information?
The reason for the convention is that "news" is generally expected to be new, so when it's not new, HN readers want to be informed of that fact, and they can react to the submission accordingly. It's a simple courtesy to readers.
> Why would someone even submit an article with out of date information?
Anything that good hackers would find interesting is on topic.[1] This includes some history.
[1] https://news.ycombinator.com/newsguidelines.html
History is not the same as out-of-date information.
The submitted article is not an historical review. If there was an article written explaining how Disk Utility had a bug, but the bug is now fixed, that might be interesting. On the other hand, to submit an article about a bug that no longer exists, with no explanation, would simply be misleading, out-of-date information. In this case, however, the bug still exists presently, so it's not history either.
> Why would someone even submit an article with out of date information?
The incredulous tone of this hypothetical worries me, because I think this actually happens with troubling regularity.
That link does not go to a comment.
I think he means https://news.ycombinator.com/item?id=45322650
Sad how a large company such as Apple cant be bothered to fix many reported bugs.
I've reported a trivially reproducible mmap issue that causes Darwin to spiral into locking up with no apparent reason. "Not a vulnerability".
I also reported a bug in Safari HTTP proxy handling that prevents encryption. No reply.
I provided source code, and reproduction steps for both.
Fuck Apple
A few years back I found a bug that would make deleted photos show up in the Photos app on iPhone simply by putting transparent PNGs into the photo library. I reported it to Apple via web, no response. I called their support and talked to a very nice guy who had an in-depth conversation with me about it and even watched a video I made showing the bug. He said he was taking the issue "up the chain." About 6 months and two .x.x releases later and the bug still existed. I reported it again, no response.
So I emailed AppleInsider who did a short article about it and within two weeks another .x.x release came out and the bug was fixed.
Sadly I think this is one of the only ways to get big tech companies to take action these days. Cant tell you how many times I have read about Comcast, Verizon, etc screwing someone over and being unreasonable about it until theres an article on ArsTechnica or some similar site about it.
These companies don't care about having reliable products, they care about the average consumer having the perception that their products are reliable.
This is the reason security researchers started demanding deadlines before publishing their findings publicly. Forcing them to do damage control by publishing their dirty laundry turned out to be the best way to motivate companies to listen to reports.
This article is from 2021. I’m curious if the problem has been addressed since then
I faced the problem today on Tahoe. See my other comment:
https://news.ycombinator.com/item?id=45322650
Apple basically stopped working on non-BS macos features 10-15 years ago. The FDE unlock on boot ssh was literally shocking for this reason. Apple’s software priority is iOS DAU.