View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00013231003.1(2016/18)/Issue7+TC2Base Definitions and Headerspublic2020-02-07 10:102024-06-11 09:08
Reportergeoffclare Assigned To 
PrioritynormalSeverityObjectionTypeClarification Requested
Status ClosedResolutionAccepted As Marked 
NameGeoff Clare
OrganizationThe Open Group
User Reference
Section<sys/stat.h>
Page Number392
Line Number13324
Interp Status---
Final Accepted TextSee 0001323:0004778.
Summary0001323: st_nlink is the number of hard links in the file system
DescriptionThe 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 ActionOn 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.

Tagstc3-2008

Activities

dannyniu

2020-02-07 11:55

reporter   bugnote:0004774

Last edited: 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
$

dannyniu

2020-02-07 12:27

reporter   bugnote:0004775

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

stephane

2020-02-07 13:24

reporter   bugnote:0004776

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.

geoffclare

2020-02-07 14:27

manager   bugnote:0004777

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.

geoffclare

2020-02-07 14:41

manager   bugnote:0004778

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.

shware_systems

2020-02-07 18:22

reporter   bugnote:0004779

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