Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001314 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Comment Clarification Requested 2020-01-05 11:19 2020-03-13 12:11
Reporter dannyniu View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
Name DannyNiu/NJF
Organization
User Reference
Section <sys/stat.h>
Page Number Rationale
Line Number Paragraphs 5 and 6.
Interp Status ---
Final Accepted Text Note: 0004772
Summary 0001314: Should file stat uniqueness proposition be moved to normative parts?
Description The current text in the Rationales section of the <sys/stat.h> header have the following 2 paragraphs that appears to specify normative requirements but is being placed in informative section.

Note that st_dev must be unique within a Local Area Network (LAN) in a ``system'' made up of multiple computers' file systems connected by a LAN.

Networked implementations of a POSIX-conforming system must guarantee that all files visible within the file tree (including parts of the tree that may be remotely mounted from other machines on the network) on each individual processor are uniquely identified by the combination of the st_ino and st_dev fields.

Should they be moved up to normative section of the specification for the header?
Desired Action Decide whether to move the 2 paragraph to normative section(s) or not.
Tags tc3-2008
Attached Files

- Relationships

-  Notes
(0004704)
shware_systems (reporter)
2020-01-06 16:24

It's my understanding that these are in Rationale because details of such remote "mounts" are considered out of scope of the standard. It is more guidance to implementors about what may be needed when applications need to pay attention to those fields. Applications based on URLs, or other access varieties over a network, may not care at all about what values are in dev or ino fields.
(0004708)
kre (reporter)
2020-01-07 00:12

Perhaps, in light of Note: 0004704 which seems reasonable, a solution might be
to expand the text in the rationale a little (or a bit more than a little)
to be something like

    This standard requires that any (st_dev, st_ino) tuple visible on a
    system uniquely identifies a particular file (or file like object)
    at the time the reference is produced. Implementations with the
    ability to combine file systems from multiple systems, each with their
    own uncoordinated (st_dev, st_ino) namespaces, such as network accessed
    file systems, must ensure that any such tuple received from some other
    system does not conflict with any such tuple from the local system or
    any other accessible remote system. The mechamism by which this is
    achieved is unspecified.
(0004718)
shware_systems (reporter)
2020-01-10 18:11

While I agree with the thought of Note 4708, it does not address the problem exists with removeable media also. Two separate CD-ROMs, as example, may have the same ino values, that are not modifiable, referencing data. If the platform is caching stat data for multiple media, an additional media id value needs to be part of that tuple to uniquely identify a file, that I see.
(0004719)
kre (reporter)
2020-01-10 23:43

Re Note: 0004718

First, we are not going to invent new mechanisms here, even if one were
wanted, so "an additional media id value" is not going to happen.

But you seem to have missed the "at the time the reference is produced"
part of the suggestion - nothing has ever expected dev/ino tuples to be
unique over all time, while the ino numbers on a filesystem tend to be
stable, even those can refer to different files over time (rm file1; > file2)
[nb: this is not expected to have file1 & file2 use the same ino number, but
it might].

But the dev part relates entirely to the way the device is connected to
the system, and can vary depending upon issues like the order in which
devices are attached, or which port they are connected to.

Whenever the filesystem attachments alter, the dev_t can alter as well,
systems which cache inodes need to flush that cache whenever the data
in it would (or might) become invalid - such as when ejecting a CD, or
unplugging a USB stick. As long as that is done correctly, a particular
dev/ino tuple will uniquely identify a file (or not exist at all) at one
instant of time - and if we're lucky (nothing changes in the filesystems)
for some time after.
(0004722)
dannyniu (reporter)
2020-01-12 03:07
edited on: 2020-01-14 03:20

Very true of Kre, the uniqueness can only guaranteed at an instant of time.

Can we put something like the following into the normative parts, I've thinked of the wording for some time:

> At any given time in a system, files of distinct identities shall have (st_dev,st_ino) tuples of distinct values; the same file or hard links to the same file shall have the same (st_dev,st_ino) value.

I'm quite satisfied with the part before the semicolon, the 2nd part might need some work I think.

(0004772)
geoffclare (manager)
2020-02-06 17:12

On page 392 line 13342 section <sys/stat.h>, change:
The st_ino and st_dev fields taken together uniquely identify the file within the system.
to:
A file identity is uniquely determined by the combination of st_dev and st_ino. At any given time in a system, distinct files shall have distinct file identities; hard links to the same file shall have the same file identity. Over time, these file identities can be reused for different files. For example, the st_ino value can be reused after the last link to a file is unlinked and the space occupied by the file has been freed and the st_dev value associated with a file system can be reused if that file system is detached ("unmounted") and another is attached ("mounted").


On page 2197 line 70223 section unlink(), add the following:
When the space occupied by the file has been freed, the file's serial number (st_ino), and therefore the file identity (see [xref to <sys/stat.h>]), shall become available for reuse.

- Issue History
Date Modified Username Field Change
2020-01-05 11:19 dannyniu New Issue
2020-01-05 11:19 dannyniu Name => DannyNiu/NJF
2020-01-05 11:19 dannyniu Section => <sys/stat.h>
2020-01-05 11:19 dannyniu Page Number => Rationale
2020-01-05 11:19 dannyniu Line Number => Paragraphs 5 and 6.
2020-01-06 16:24 shware_systems Note Added: 0004704
2020-01-07 00:12 kre Note Added: 0004708
2020-01-10 18:11 shware_systems Note Added: 0004718
2020-01-10 23:43 kre Note Added: 0004719
2020-01-12 03:07 dannyniu Note Added: 0004722
2020-01-14 03:20 dannyniu Note Edited: 0004722
2020-02-06 17:12 geoffclare Note Added: 0004772
2020-02-06 17:13 geoffclare Interp Status => ---
2020-02-06 17:13 geoffclare Final Accepted Text => Note: 0004772
2020-02-06 17:13 geoffclare Status New => Resolved
2020-02-06 17:13 geoffclare Resolution Open => Accepted As Marked
2020-02-06 17:13 geoffclare Tag Attached: tc3-2008
2020-03-13 12:11 geoffclare Status Resolved => Applied


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