|Anonymous | Login | Signup for a new account||2017-11-22 09:19 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001146||[1003.1(2016)/Issue7+TC2] Shell and Utilities||Objection||Error||2017-06-15 19:50||2017-06-15 19:50|
|Final Accepted Text|
|Summary||0001146: "total" line in ls -l output|
The current text says:
> If any of the -l, -n, -s, ^[XSI] [Option Start] -g, or -o
> [Option End] options is specified, each list of files
> within the directory shall be preceded by a status line
> indicating the number of file system blocks occupied by
> files in the directory in 512-byte units if the -k option
> is not specified, or 1024-byte units if the -k option is
> specified, rounded up to the next integral number of
> units, if necessary. In the POSIX locale, the format
> shall be:
> "total %u\n", <number of units in the directory>
However, that's not what I observe with existing implementations
(I checked GNU, busybox, Solaris 10 and FreeBSD 11)
Instead, the number after "total" seems to be the sum of the
disk usage (as in ls -s) of all the entries listed.
With -a, that includes all hidden files and . and .. if present,
with -A hidden files but not . nor ..
With neither -A nor -a, that only counts the disk usage of
With -L, that's the sum of the disk usage of the files
referred to by the directory entries after symlink resolution.
In any case, if a file is listed twice by two different entries (hard links or soft links with -L), its disk usage is counted twice.
Of course with -L, for symlinks whose targets are not
accessible, the corresponding disk usage is not accounted for.
Clarify that the total number is the sum of the st_blocks (from lstat() or stat() with -L) of the files for each of the entries *that are listed* only (we probably need a separate bug to clarify what should happen in general for entries for which lstat() or stat() fails).
Maybe mention in an "application usage" section, that even without -L, the number doesn't necessarily correspond to the space that would be reclaimed if all the listed files were removed because of hard links.
|Tags||No tags attached.|
|There are no notes attached to this issue.|
|2017-06-15 19:50||stephane||New Issue|
|2017-06-15 19:50||stephane||Name||=> Stephane Chazelas|
|2017-06-15 19:50||stephane||Section||=> ls utility|
|2017-06-15 19:50||stephane||Page Number||=> 2928|
|2017-06-15 19:50||stephane||Line Number||=> 96855|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|