2

I've created multiple hard-links to a file in a folder to illustrate the issue.

~/Test $ ln original.pdf link1.pdf
~/Test $ ln original.pdf link2.pdf
~/Test $ ls -li
403963 .rw-r--r--@ 3 80k username 2017-11-29 20:17 original.pdf
403963 .rw-r--r--@ 3 80k username 2017-11-29 20:17 link1.pdf
403963 .rw-r--r--@ 3 80k username 2017-11-29 20:17 link2.pdf

You can see above they all have the same inode: 403963.

The du utility reports the total size of the folder as the size of the actual data pointed at by those links.

~/Test $ du -sh .
 80K  .

But Finder's adds up each of the link's size (plus something else) when reporting the folder size in the "Get Info" window. If you're wondering why it says "4 items", I guess it's because it also counts the folder itself. There are definitely only those three files in the "Test" folder.

Get Info window

Is there any option to configure Finder to count multiple hard links to the same inode only once?

1 Answer 1

0

The short answer is there is no option to configure Finder to count multiple hard links to the same inode only once. The Finder reports the sum of the current sizes of all files and folders contained within a folder. Extra storage required for versioning is not included and saving in storage though the use of copy-on-write or multiple hard links to the same file is not reported.

A longer Explanation of How APFS Allocates Storage

The size value displayed in OP's image is the sum of the sizes of the files in the folder. The OP wants this to be the space occupied by the files in the folder. This is what the OP thinks du -sh . command does, but this would be incorrect. Under APFS there is copy-on-write. The du -sh . command does not take this in account and thus can report an incorrect value.

Below is an example.

The commands below create a 60 MB file named original in a folder name test on a 100 MB APFS volume named question.

hdiutil create -size 100M -type UDIF -fs APFS -volname question ~/Desktop/question.dmg
hdiutil attach ~/Desktop/question.dmg
mkdir /Volumes/question/test
cd /Volumes/question/test
dd if=/dev/zero of=original bs=60000000 count=1

Below is an image from Get Info of the test folder and question volume. The test folder uses 60 MB and the question volume uses a slightly larger amount do to other smaller files and folders.

before

The output from the commands ls -li and du -sh . are given below. Here, the du -sh . command outputs 57 MiB with agrees with the 60 MB size of the original file. (57 MiB = 60 MB)

$ ls -li
total 117192
19 -rw-r--r--  1 davidanderson  staff  60000000 Jan  1 19:32 original
$ du -sh .
 57M    .

Next, the command show below was entered, which uses copy-on-write to make a copy of the original.

cp -c original copy

The image below shows the test folder has doubled in size. This is the sum of the sizes of the files original and copy. The volume question has not changed in size.

after copy

The output from the commands ls -li and du -sh . are given below. Here, the du -sh . command outputs the sum of the sizes output by the command ls -li. (114 MiB = 120 MB)

$ ls -li
total 234384
21 -rw-r--r--  1 davidanderson  staff  60000000 Jan  1 19:32 copy
19 -rw-r--r--  1 davidanderson  staff  60000000 Jan  1 19:32 original
$ du -sh .
114M    .

Next, the command show below was entered, which created a new hard link named link to the original file.

ln original link

Below is an image from Get Info of the test folder and question volume. Again, the used space in the question volume has not changed. The size of the test folder has tripled from the original size of 60 MB.

after ln

The output from the commands ls -li and du -sh . are given below.

The value output from the du -sh . command is neither the space occupied by the files nor is the value the sum of the file sizes.

$ ls -li
total 351576
21 -rw-r--r--  1 davidanderson  staff  60000000 Jan  1 19:32 copy
19 -rw-r--r--  2 davidanderson  staff  60000000 Jan  1 19:32 link
19 -rw-r--r--  2 davidanderson  staff  60000000 Jan  1 19:32 original
$ du -sh .
114M    .

Therefore, there would be no reason for an option to configure Finder to count multiple hard links to the same inode only once. In other words, there is no reason to create an option replicate a value with may not represent a meaningful value. The OP wants Get Info on folder to present the space used by the files in the folder. This would be a difficult (and therefore time consuming) value to determine. For example, the following command was entered to overwrite the first 30 MB of the original file.

dd if=/dev/zero bs=30000000 count=1 of=original conv=notrunc

The image below shows the test folder size is unchanged. However, the volume question used space has increased by approximately 30 MB.

after overwrite

The output from the commands ls -li and du -sh . are given below. The original and link files still have the same inode number, but now do to copy-on-write only the last 30 MB of these files is shared with the last 30 MB of the copy file. So, while the file sizes have not changed, 30 MB of disk space needed to be allocated to hold the 30 MB of zeroes written out by the dd if=/dev/zero bs=30000000 count=1 of=original conv=notrunc command. Again the ls -li command does not show any change.

$ ls -li
total 351576
21 -rw-r--r--  1 davidanderson  staff  60000000 Jan  1 19:32 copy
19 -rw-r--r--  2 davidanderson  staff  60000000 Jan  2 02:00 link
19 -rw-r--r--  2 davidanderson  staff  60000000 Jan  2 02:00 original
$ du -sh .
114M    .

Determining the amount of space used by a folder is more complicated than just looking at the file size and ignoring a size when a duplicate inode number is found. The Get Info for a volume can do this by simply subtracting the free space from the total space to get the used space. The Get Info for a folder would have to make sure a block or sequence of blocks are not be counted more than once. IMO, macOS does not do this because doing so would be to time consuming. To be fair, I could be wrong about this. For example, WGroleau has expressed essentially the opposite view.

5
  • OP didn't ask whether there is a reason to do it, they asked whether there is a way to do it. And I have to disagree with "there is no reason." Finder is reporting a size that is NOT correct. The method for coming up with the wrong number does not justify it being wrong.
    – WGroleau
    Jan 2, 2021 at 2:28
  • @WGroleau: The OP is asking for the space occupied by the files in a folder. This would be difficult to determine. The software would have to look at every 4 KiB block used by each file in the folder (and subfolders) to determine if the block is being occupied by some other file in the folder (or subfolder). This would be quite a time consuming process. The OP assumed the du -sh . command already does this, which the command does not. Jan 2, 2021 at 2:37
  • There are several takes on this: do Finder/du show the actual number of bytes occupied, do they show the size relevant for practical purposes (e.g. can I copy this folder to a specific USB stick), do they show the same number. While I see value in the first option, there also is value in the others.
    – nohillside
    Jan 2, 2021 at 8:02
  • 1
    Indeed, I am mostly interested in knowing if there is a way then decide how to manage my digital assets based on that. I wish hard-links were counted only once because that's the real size of multiple links pointing to the same data. I have many names but my weight doesn't increase because of that and IMO (soft|hard) links to some sequence of bytes should also not increase the reported total size. If you added a TL;DR on top of your answer saying that's not possible I'd accept your answer and read the technical explanation as why that's the case later. Thanks for sharing so much knowledge!
    – acorello
    Jan 2, 2021 at 20:47
  • @protoboolean: I edited my post to add an abbreviated answer at be beginning. Jan 2, 2021 at 22:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .