Question

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?

Was it helpful?

Solution

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with apple.stackexchange
scroll top