View Issue Details

IDProjectCategoryView StatusLast Update
00011461003.1(2016/18)/Issue7+TC2Shell and Utilitiespublic2024-06-11 09:09
Reporterstephane Assigned To 
PrioritynormalSeverityObjectionTypeError
Status ClosedResolutionAccepted As Marked 
NameStephane Chazelas
Organization
User Reference
Sectionls utility
Page Number2928
Line Number96855
Interp StatusApproved
Final Accepted TextSee 0001146:0004172
Summary0001146: "total" line in ls -l output
DescriptionThe 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
non-hidden files.

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.
Desired ActionClarify 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.
Tagstc3-2008

Activities

nick

2018-11-29 17:05

manager   bugnote:0004172

Interpretation response
------------------------
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.

Rationale:
-------------
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:

... 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 ...


to:

... each list of files within a directory shall be preceded by a status line indicating the number of file system blocks occupied by the listed files for that directory ...

Add to Application Usage on p2930 after line 96908:

The <tt>total</tt> number provided when using ls -l does not necessarily
correspond to the space that would be reclaimed if all the listed files
were removed, because of hard links (and symbolic links if -L
is present). The space for each listed file is counted in the total regardless of any relationship between the files.

agadmin

2018-12-06 17:24

administrator   bugnote:0004174

Interpretation proposed: 6 December 2018

agadmin

2019-01-08 14:30

administrator   bugnote:0004197

Approved 8 Jan 2019

Issue History

Date Modified Username Field Change
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 0001146: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
2024-06-11 09:09 agadmin Status Applied => Closed