0

Given the following find command and output

21 $ find . -name foo -ls
80960162    0 -rw-rw-r--   1 kimelmab ccV983         29 Nov 29 07:28 ./foo

The 1st number is the i-node number and 3rd number is the number of links. But what does the 2nd number (i.e. the zero) represent ?

Barry Kimelman
  • 103

3 Answers3

2

It's the number of (by default, 1K) blocks. From the description of -ls in the texinfo documentation (info find -n 'Print File Information'):

 -- Action: -ls
     True; list the current file in 'ls -dils' format on the standard
     output.  The output looks like this:

      204744   17 -rw-r--r--   1 djm      staff       17337 Nov  2  1992 ./lwall-quotes

 The fields are:

   1. The inode number of the file.  *Note Hard Links::, for how to
      find files based on their inode number.

   2. the number of blocks in the file.  The block counts are of 1K
      blocks, unless the environment variable 'POSIXLY_CORRECT' is
      set, in which case 512-byte blocks are used.  *Note Size::,
      for how to find files based on their size.

   3. The file's type and file mode bits.  The type is shown as a
      dash for a regular file; for other file types, a letter like
      for '-type' is used (*note Type::).  The file mode bits are
      read, write, and execute/search for the file's owner, its
      group, and other users, respectively; a dash means the
      permission is not granted.  *Note File Permissions::, for more
      details about file permissions.  *Note Mode Bits::, for how to
      find files based on their file mode bits.

    ...
steeldriver
  • 136,215
  • 21
  • 243
  • 336
1

It seems to me that the second column in the output of

find -ls

is the drive space occupied in kibibytes, corresponding [at least for files] to the output of du (default matching du -k). For directories it is the drive space occupied for the directory structure itself (not including the data in the files in the directory, but the addresses to the files, so the number increases, when there are many files in the directory).

Please notice that in current Ubuntu systems, the minimum drive space allocated to a file is 4 kibibytes.

sudodus
  • 46,324
  • 5
  • 88
  • 152
  • I don't know why there is a zero in the second column of your example. What kind of operating system, file system and what kind of file is it? Is it an empty file or a link? – sudodus Nov 29 '23 at 13:51
  • 2
    When the file is empty, it's merely occupies some space in its parent directories meta-data so only adds to the size used by its parent directory as its meta-data increase but the file itself will occupy 0 space on disk and is reported as such until some data is written to it in which case it will start increasing allocated size on disk in one block increments regardless of the actual data size in it which could be actually less than that ... compare after touch file and then after echo "1" > file and notice the reported used disk space for file in both cases. – Raffa Nov 29 '23 at 14:11
  • 1
    Thanks for the details @Raffa :-) But have a look at the example in the original question: What is the '29' before 'Nov'? Or after, anyway, the date of month should not be printed twice, so I don't understand it. – sudodus Nov 29 '23 at 15:46
  • 1
    Ah, I missed that ... that is supposed to be the actual file's size (contents) in bytes ... a symbolic link can report some few bytes 4 but not that much AFAIK and the file doesn't appear to be a symbolic link anyway ... In this case it could be actually 29 bytes on a filesystem that allows less than a block and the 0 in -ls output should be valid in this case as it counts only 1K and up ... see NTFS test here for example ... That's assuming th 29 is not a typo ... Good catch :-) – Raffa Nov 29 '23 at 16:25
  • 1
    ... or a filesystem with block size set to less than 1K although not common ... so the 29 bytes although occupy a full block but still that one block is not enough (less than 1K) to appear as 1 in the output of -ls I think. – Raffa Nov 29 '23 at 16:33
1

Not, answering about what the second field is particularly as that is well covered in the other two answers by @sudodus and @steeldriver, but rather about its reported 0 blocks value and how it relates to the seventh field and its 29 value which is the file's size reported in bytes and particularly on how the file is reported to have a 29 bytes size and yet still the used blocks reported is 0 (noted in the comment by @sudodus)... as the normal behavior for a file is to use zero blocks on disk when it's empty and a minimum of one block when it contains data no matter how small the size of the data compared to the size of the block (see more explanation here):

## Get filesystem info:
$ stat -f .
  File: "."
    ID: ea0dd13726e1c7f1 Namelen: 255     Type: ext2/ext3
Block size: 4096       Fundamental block size: 4096
Blocks: Total: 239946508  Free: 140401510  Available: 128194458
Inodes: Total: 61022208   Free: 59882281
$
## Create an empty normal file an examine it with "find"'s action "-ls"
$ touch file1
$
$ find . -name "file1" -ls
 20578311      0 -rw-rw-r--   1 ubuntu   ubuntu          0 Nov 30 11:22 ./file1
$
## Write some data into the file and examine it again
$ printf '%s' "1" >> file1 
$
$ find . -name "file1" -ls
 20578311      4 -rw-rw-r--   1 ubuntu   ubuntu          1 Nov 30 11:26 ./file1

... there might be some explanation to that as follows (these are some of and not all the possibilities):

Under Ubuntu's current default filesystem EXT4 and default 4K block size

The file might be a sparse file ... as (on filesystems that support it) the contents of those files are dynamically generated by the filesystem at runtime when the file is read:

## Get filesystem info:
$ stat -f .
  File: "."
    ID: ea0dd13726e1c7f1 Namelen: 255     Type: ext2/ext3
Block size: 4096       Fundamental block size: 4096
Blocks: Total: 239946508  Free: 140401510  Available: 128194458
Inodes: Total: 61022208   Free: 59882281
$
## Create a sparse file of "29" bytes size and examine:
$ truncate -s 29 file2
$
$ find . -name "file2" -ls
 20578315      0 -rw-rw-r--   1 ubuntu   ubuntu         29 Nov 30 11:30 ./file2
$
## Increase the size of the sparse file and examine again:
$ truncate -s 1G file2
$
$ find . -name "file2" -ls
 20578315      0 -rw-rw-r--   1 ubuntu   ubuntu   1073741824 Nov 30 11:32 ./file2

Under other filesystems

Allocating less than a full block size on disk might be allowed ... For example NTFS:

## NTFS filesystem:
$ stat -f .
  File: "."
    ID: 0        Namelen: 255     Type: fuseblk
Block size: 4096       Fundamental block size: 4096
Blocks: Total: 1048575    Free: 1043189    Available: 1043189
Inodes: Total: 4205524    Free: 4205505
$
$
$ touch file
$
$ find . -name "file" -ls
       64      0 -rwxrwxrwx   1 root     root            0 Nov 30 11:59 ./file
$
$ printf '%s' "1" >> file
$
$ find . -name "file" -ls
       64      1 -rwxrwxrwx   1 root     root            1 Nov 30 12:01 ./file
$
$ head -c 29 /dev/zero > file
$
$ find . -name "file" -ls
       64      1 -rwxrwxrwx   1 root     root           29 Nov 30 12:03 ./file
$
$ head -c 1k /dev/zero > file
$
$ find . -name "file" -ls
       64      4 -rwxrwxrwx   1 root     root         1024 Nov 30 12:03 ./file

... other filesystems than NTFS might allow even less than that i.e. less than the 1K required by find's action -ls to report as 1.

Raffa
  • 32,237