0

I have a large directory structure that has many hard links from the first hard link which lives in a different directory structure. For example dir1 has the following structure :

[dir1]$ tree
.
├── dir_inside
│   ├── file1
│   └── file2
└── other_dir
    ├── file1
    └── file2

Now lets suppose dir2 exists outside dir1 and all files in dir1 e.g. file1 and file2 are hard links of files that primarily existed in dir2 i.e. files in dir2 existed before dir1 was created.

When calculating the size of dir1 I would go for the command du -sh dir1 since du will only count hard-links only once. Ok so far so good, but by counting only once this means that I am actually counting not from the first hard link which lives in dir2. So let's say du -sh dir2 is 2G in size. dir1 will also be 2G in size since the hard link will be counted once in that directory structure. As far as my knowledge in hard-links concern I believe hard-links do not actually have the same file size as the first inode created right ? I would really enjoy getting some clarification on getting the directory size of hard-link files that live in different directories, thus getting an estimation of the real disk space the hard-links are occupying.

1
  • A hard link is basically a new name for the same data. You can't say that one is a link to the other. They are just two names for the same data.
    – Kusalananda
    Dec 29 '20 at 12:28
1

I think you misunderstand the concept of a hard link.
A file[name] is a pointer to an inode, a hard link is exactly the same. There is no reference to the original file.

du cannot know if a file was created as a hard link from another file. du can only filter if multiple pointers to an inode appear in a single du call:

du -sh dir1 dir2
2
  • A file-name (not a file). [2nd paragraph] Dec 29 '20 at 12:27
  • but this command du -sh dir1 dir2 will give the size for each of the directories and not for the intersection of hardlinks between those directories which have inodes in common. any way to get the intersection ?
    – moth
    Dec 30 '20 at 2:12
0

You have some miss-understanding of hard links.

The first think to note is there is no such thing, or that every file [name] is a hard link.

Yes that is correct, there is no special structure for hard-links. So what are they.

Every file has an inode. The inode points to the content, and to meta-data: file-mode, size, dates, etc.

Then there are file-names. Each file-name points to exactly one inode. Each inode can have between zero and many file-names point at it. (Each inode can have between zero and many open file-descriptors (owned by processes) point to it). If there are zero file-names, and zero file-descriptors pointing to an inode, then it is garbage collected.

There is no record of the order that these file-names, file-descriptors were created. Therefore it can not be said that this one is a hard-link and this one is the original. This distinction only exists at the point of creation. After that there are indistinguishable.

4
  • thanks for the info, but what about the actual size of hard-links ? you said they are indistinguishable, so are they also indistinguishable in size ? i thought hard-links main purpose is to save disk space.
    – moth
    Dec 30 '20 at 2:16
  • @alex size is stored in the inode. So when you make a hard link to the same inode as another name, it is the same file, with same size. EVERYTHING is shared, except the name in the directory entry. However some tools will count it twice. Dec 30 '20 at 7:52
  • ok thanks. Do you know a tool that can count only once across different directories ? for example du -sh dir1 dir2 counts each individual directory only one time the hard-link. What about counting one time together across directories ? thanks
    – moth
    Dec 30 '20 at 9:38
  • du does what you want. However you are running it separately for each directory, and expecting it to remember. Pass it all of the directories that it needs to measure: du -sch dir1 dir1 … Dec 30 '20 at 10:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.