Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
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 2024-06-11 09:09
Reporter stephane View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Stephane Chazelas
Organization
User Reference
Section ls utility
Page Number 2928
Line Number 96855
Interp Status Approved
Final Accepted Text See Note: 0004172
Summary 0001146: "total" line in ls -l output
Description 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
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 Action 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 tc3-2008
Attached Files

- Relationships

-  Notes
(0004172)
nick (manager)
2018-11-29 17:05

 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.
(0004174)
agadmin (administrator)
2018-12-06 17:24

 Interpretation proposed: 6 December 2018
(0004197)
agadmin (administrator)
2019-01-08 14:30

 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 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
2024-06-11 09:09 agadmin Status Applied => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker