Hacker News Reader

Comment by tumult | Hacker News Reader

You're making the mistake that you're accusing the article of. Of course the author knows these things. As you just showed. Yet, the Finder GUI still reports bad information. Information that can mislead users into making bad decisions. That's what this article is complaining about. The article is talking about Finder, the GUI. It's showing screenshots. It's not talking about probing for CoW status using CLI filesystem tools. What are regular users supposed to do? A sanity check would at least have the Finder report nothing instead of incorrect information.

View on HN

Saying that finder should sum file sizes in a way that accounts for this makes sense.

I'm not sure adding a separate "Sanity check" would help though. If the sanity check is that the reported file sizes shouldn't exceed the disk size, that's still a lie.

If you have 1000 duplicate 10GB files that are sharing storage blocks in the file system, that's either 10TB or 10GB of stored files depending on how you count it. Reporting 2TB because that's the size of the disk is a less accurate answer than either of those.

Sanity check, not min().

What value is sane in this case?

You're making the same mistake if you think that's "incorrect information", because it isn't --- there is a clear and logical reason why the sizes are reported the way they are, and if you'd only take some effort to learn instead of complaining because they don't fit your incorrect assumptions, you'd understand.

A sanity check would at least have the Finder report nothing instead of incorrect information.

You're saying to just not show any size at all if the filesystem contains more data than its capacity, which is basically going to be 100% of the time after enough backups are made? WTF. That makes even less sense.

I'm not one to trust AI much at all, but I bet even an LLM these days would know and tell you why the total size of all the files on a filesystem can appear to exceed the capacity of the storage device.

> You're making the same mistake if you think that's "incorrect information"

No, that would be a different type of mistake.

> you'd only take some effort to learn instead of complaining because they don't fit your incorrect assumptions

I know exactly why it reports it like this. That wasn't the point of the article, and not the point of my reply.

> You're saying to just not show any size at all if the filesystem contains more data than its capacity, which is basically going to be 100% of the time after enough backups are made? WTF. That makes even less sense.

No, not 100% of the time. But it would be a significant portion of time, yes. The Finder should probably not even try to report the information like this if it's going to be misleading such a high percentage of the time, if Apple is not going to add a better way for users to account for where all of the space on their drives is going.

> I'm not one to trust AI much at all, but I bet even an LLM these days would know and tell you why the total size of all the files on a filesystem can appear to exceed the capacity of the storage device.

I tried to find a way to interpret this other than, "you should just use ChatGPT as a person to talk to, because ChatGPT is smarter than you and could explain to you how filesystems work," but I wasn't able to.

Why did you add

> because ChatGPT is smarter than you

? It's really weird framing.

Because the reply was written like this:

> … but I bet even an LLM these days would know and tell you …

The "even" here says that knowledge of the filesystem is basic.

> I'm not one to trust AI much at all …

This part shows that the person replying does not think highly of AIs.

Together: AIs aren't very smart, but they at least know about filesystems and could explain it to you.

respect for something's knowledge seems orthogonal to trust to me. I can respect a serial killers intelligence without remotely trusting him.

Maybe Finder could display two values, size on disk and total bytes in files, or something like that. At least some hint to the user that the software knows what it's doing.

This idea where "the user is wrong when their understanding of the software/computer doesn't match the particular mental model the software developer had in mind" is one of the reasons why software is so bad. This particular author probably knows why the numbers look weird, but he is writing from the point of view of a layman user (99% of users out there) who would have the exact questions. If my elderly parents had a 2TB drive and their computer said it was doing something with 60TB of files, they would be right to question that number.

It might not be technically incorrect but it certainly isn't very useful information.

What does it matter if there is one backup of a 1GB file or 100 deduped backups of the same file? Telling me that the backup of that file takes up 100GB is not useful information in any way that I can think of, it's just a convoluted way of telling me how many backups I've made.

It is not actually taking up 100GB of space nor do I need 100GB available to restore the backup.

However, the information is not wrong to begin with. You can extract that amount of data from the disk if you copy the filesystem to another filesystem which does not support these features.

No. There is not 60TB of data on the disk, which is what the GUI is reporting in the article. The GUI doesn't say that 60TB of data would exist if the snapshots were each individually flattened and expanded to another filesystem. It says there is 60TB of data filling the disk.

However, the code traverses that amount of data. It doesn't matter if you pass over the same inode n times. From OS point of view, there's no difference.

Of course you can write a more complicated calculation algorithm, but it'll require tons of syscalls to determine the type of the file handle you're interacting with and will be probably very slow.

This is what rustup did inadvertently back in the day, and it caused NTFS to melt down to a halt because of stat() overhead [0].

[0]: https://www.youtube.com/watch?v=qbKGw8MQ0i8

Why does the user care about how many times an iterator passes over an inode? The Finder is reporting incorrect information to them and may lead them to make bad decisions, like buying unnecessary external storage drives. You've missed the point of the article.

I don't think so, because a) macOS provides correct free space information, b) It explicitly says that "your backup disk is full, and I'll open up some space, so your earliest backup will be at $DATE", before actually deleting any snapshots.

Our disagreements stem from the assumption that the reported space is incorrect to begin with, but there's already "disk on space" note on every file, which provides physical size of something.

We can argue that the progress may be calculated over that number, but I still think it has its own limitations with performance.

I think that's fair when you consider it all together.

What happens then if you try to copy that 2TB of 'data' to a filesystem that doesn't support links? 60TB would be used in that case.

There are some use cases that are computationally expensive to figure out and don't have a simple/easy answer to solve.

That's not the information that dialog is purporting to display. That's a theoretical thing you've made up for this comment.

It's a real thing that happens all the time when copying. Delete is a different operation, but now you're asking for a different space calculator when performing delete which will have its own set of bugs and performance issues.

Hard links are a pathological case.

Reply on news.ycombinator.com