Re: Hard link count reported by "ls -l" is wrong

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 25, 2020 at 09:59:49AM -0500, Franklin, Jason wrote:
> Greetings:
> 
> I'm using btrfs on Debian 10.
> 
> When using "ls -l" to view a detailed listing in the current directory,
> I get output similar to the following:
> 
> total 0
> drwxrwx--- 1 jfrankli jfrankli  38 Feb 25 09:54 Desktop/
> drwxrwx--- 1 jfrankli jfrankli  36 Jan 24 10:37 Documents/
> drwxrwx--- 1 jfrankli jfrankli 612 Feb 24 15:48 Downloads/
> drwxrwx--- 1 jfrankli jfrankli   0 Nov  6 04:44 Music/
> drwxrwx--- 1 jfrankli jfrankli  20 Nov  6 04:44 Pictures/
> drwxrwx--- 1 jfrankli jfrankli   0 Nov  6 04:44 Public/
> drwxrwx--- 1 jfrankli jfrankli   0 Dec 27 20:20 Templates/
> drwxrwx--- 1 jfrankli jfrankli   0 Dec 27 20:20 Videos/
> drwxrwx--- 1 jfrankli jfrankli 522 Nov 26 09:53 bin/
> drwxrwx--- 1 jfrankli jfrankli  28 Dec 27 15:23 snap/
> 
> Notice that these are all directories with a hard link count of "1".
> 
> I have always seen directories possessing a hard link count of "2" or
> greater.  This is because the directory itself is a hard link, and it
> also contains the "." entry (the second hard link).
> 
> Any immediate child directory of a directory also adds +1 to the hard
> link count on other file systems.  This is because each child directory
> contains the ".." hard link pointing to its parent directory.
> 
> Why does this not happen with btrfs?
> 
> Could it a bug with the GNU "ls" tool?

No, link count 1 for directories is valid, btrfs does not implement
exact tracking like other filesystems.

https://btrfs.wiki.kernel.org/index.php/Project_ideas#Track_link_count_for_directories



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux