|Anonymous | Login||2021-04-15 14:10 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/18)/Issue7+TC2] Shell and Utilities||Objection||Error||2017-06-15 19:50||2019-11-05 12:19|
|Priority||normal||Resolution||Accepted As Marked|
|Final Accepted Text||See Note: 0004172|
|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.
The standard states that ls lists the space requirements for all files in a directory, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor.
This is not (and never has been) existing practice.
Notes to the Editor (not part of this interpretation):
On page 2928 line 96855 section ls, change:
Add to Application Usage on p2930 after line 96908:
|Interpretation proposed: 6 December 2018|
|Approved 8 Jan 2019|
|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|
|2018-11-29 17:05||nick||Note Added: 0004172|
|2018-11-29 17:06||nick||Interp Status||=> ---|
|2018-11-29 17:06||nick||Final Accepted Text||=> See Note: 0004172|
|2018-11-29 17:06||nick||Status||New => Interpretation Required|
|2018-11-29 17:06||nick||Resolution||Open => Accepted As Marked|
|2018-11-29 17:06||nick||Tag Attached: tc3-2008|
|2018-11-29 17:07||nick||Interp Status||--- => Pending|
|2018-12-06 17:24||agadmin||Interp Status||Pending => Proposed|
|2018-12-06 17:24||agadmin||Note Added: 0004174|
|2019-01-08 14:30||agadmin||Interp Status||Proposed => Approved|
|2019-01-08 14:30||agadmin||Note Added: 0004197|
|2019-11-05 12:19||geoffclare||Status||Interpretation Required => Applied|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|