Austin Group Defect Tracker

Aardvark Mark III

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
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
Reporter stephane View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Stephane Chazelas
User Reference
Section ls utility
Page Number 2928
Line Number 96855
Interp Status ---
Final Accepted Text
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 No tags attached.
Attached Files

- Relationships

There are no notes attached to this issue.

- 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

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