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
0001323 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Objection Clarification Requested 2020-02-07 10:10 2020-12-04 16:39
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Geoff Clare
Organization The Open Group
User Reference
Section <sys/stat.h>
Page Number 392
Line Number 13324
Interp Status ---
Final Accepted Text See Note: 0004778.
Summary 0001323: st_nlink is the number of hard links in the file system
Description The description of st_nlink is:
Number of hard links to the file.
The standard should make clear that st_nlink is the number of hard links in the file system, which can differ from the number in the entire file hierarchy on systems that support mounting the same file system multiple times at different mount points.
Desired Action On page 392 line 13342 section <sys/stat.h> add a new paragraph:
The st_nlink value shall be the number of hard links to the file within the file system in which the file resides.
Note: On some implementations a file system can be made to appear multiple times at different mount points in the file hierarchy, in which case the number of hard links to the file throughout the file hierarchy is st_nlink times the number of mount points for that file system.
Tags tc3-2008
Attached Files

- Relationships

-  Notes
(0004774)
dannyniu (reporter)
2020-02-07 11:55
edited on: 2020-02-07 11:56

 I suggest make the note indicate st_nlink as undefined, as $(st_nlink * count(mount points)) is not the actual behavior as I've observed on FreeBSD with nullfs:

$ mount -l
/dev/ada0s1a on / (ufs, local, journaled soft-updates)
devfs on /dev (devfs, local, multilabel)
/usr/home/dannyniu/sandbox on /usr/home/dannyniu/glassbox (nullfs, local)

$ ls -l sandbox glassbox
glassbox:
total 4
-rwxr-xr-x 1 dannyniu dannyniu 246 Dec 10 10:24 data2url.php

sandbox:
total 4
-rwxr-xr-x 1 dannyniu dannyniu 246 Dec 10 10:24 data2url.php
$
(0004775)
dannyniu (reporter)
2020-02-07 12:27

 Okay, I might've mis-interpreted the "note", but nonetheless I suggest make it clearer by saying:

Note: ... in which case the actual number of hard links to the file throughout the file hierarchy is st_nlink times the number of mount points for that file system (which is greater than st_nlink).
(0004776)
stephane (reporter)
2020-02-07 13:24

 I'd rather say "in which case the number of hard links to the file throughout the file hierarchy could be greater than st_nlink" as systems allow mounting *parts* of a FS (like in bind-mounts) and part of a FS can be masked by another FS (like FS2 is mounted on a non-empty directory of FS1), in which case, it could even be less than st_nlink.
(0004777)
geoffclare (manager)
2020-02-07 14:27

 Seems I was fixated on the multiple-mount-points case and hadn't thought about other situations affecting the number of links that can be "found". The less-than-st_nlink case could happen even on ancient systems that don't have modern functionality like bind mounts, etc. You just need to mount another file system over the top of a non-empty directory. I'll add a note with a revised proposal.
(0004778)
geoffclare (manager)
2020-02-07 14:41

 On page 392 line 13342 section <sys/stat.h> add a new paragraph:
The st_nlink value shall be the number of hard links to the file within the file system in which the file resides.
Note: The number of links to the file that can be found by traversing the file hierarchy can differ from st_nlink. For example, it can be less than st_nlink if a link to the file cannot be reached because it is below a directory that has been overlaid with a mount point for a different file system, and it can be greater than st_nlink on implementations that allow a file system (or part of one) to be duplicated at additional mount points.
(0004779)
shware_systems (reporter)
2020-02-07 18:22

 I agree with the clarification here, just feel what is in the Note is better as an App Usage paragraph of its own, rather than in the normative part.

- Issue History
Date Modified Username Field Change
2020-02-07 10:10 geoffclare New Issue
2020-02-07 10:10 geoffclare Name => Geoff Clare
2020-02-07 10:10 geoffclare Organization => The Open Group
2020-02-07 10:10 geoffclare Section => <sys/stat.h>
2020-02-07 10:10 geoffclare Page Number => 392
2020-02-07 10:10 geoffclare Line Number => 13324
2020-02-07 10:10 geoffclare Interp Status => ---
2020-02-07 11:55 dannyniu Note Added: 0004774
2020-02-07 11:56 dannyniu Note Edited: 0004774
2020-02-07 12:27 dannyniu Note Added: 0004775
2020-02-07 13:24 stephane Note Added: 0004776
2020-02-07 14:27 geoffclare Note Added: 0004777
2020-02-07 14:41 geoffclare Note Added: 0004778
2020-02-07 18:22 shware_systems Note Added: 0004779
2020-10-12 15:33 Don Cragun Final Accepted Text => See Note: 0004778.
2020-10-12 15:33 Don Cragun Status New => Resolved
2020-10-12 15:33 Don Cragun Resolution Open => Accepted As Marked
2020-10-12 15:33 Don Cragun Tag Attached: tc3-2008
2020-12-04 16:39 geoffclare Status Resolved => Applied

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