Comment by chmaynard | Hacker News Reader

Comment by chmaynard | Hacker News Reader

Parent Full thread

From the article:

The chflags() system call can no longer set the SF_FIRMLINK flag on a folder on an APFS volume. Rather than fail with an error code that we would have detected, it fails silently – it exits with a success exit status, but silently fails to set the special flag ... Apple preaches that you should always check your error codes, and we do – religiously. This bug slipped past us for who knows how long because the system call exits with a success error code ... It's hard to find kind words to express my feelings towards Apple right now. Suffice it to say, though, I'm extremely disappointed that Apple would introduce this kind of bug in a dot-release OS update. We've seen 5 major updates to Catalina now, we should expect to see higher quality than this from an operating system.

Did setting SF_FIRMLINK ever succeed for real? Firmlinks are an APFS addition, and AFAIU not only can't usercode directly create firmlinks, trying to set SF_FIRMLINK with chflags is non-sensical, sort like trying to use chmod to set the S_IFDIR bit on a regular file. Apple would hardly be the first OS to silently ignore non-sensical flags in a bitfield; such problems and their dilemmas have plagued Linux syscalls for years. Though if this is a change of behavior--it previously always failed but now it doesn't--that's problematic. Alternatively, if previously chflags seemed to work--st_flags reflected the SF_FIRMLINK bit on subsequent stat, even if the inode wasn't actually a firmlink--the change would be closer to a fix than a regression. I'm more curious why you were trying to set it in the first place. Maybe I'm misunderstanding.

> Did setting SF_FIRMLINK ever succeed for real?

It should have been working fine right? Otherwise CCC team would have reported this bug in the earlier release. As what Mike Bombich said in the original post:

   The chflags() system call can no longer set the SF_FIRMLINK flag on a folder on an APFS volume.

The keyword was "no longer".

File system code is tricky. Here's a similar (but less serious) bug in Linux, with btrfs[0], where ftruncate(2) would return an "impossible"[1] value. I presume the APFS bug's probably of a similar nature.

[0] https://github.com/torvalds/linux/commit/d50147381aa0c9725d6...

[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/f...

Reply on news.ycombinator.com