0001314: Should file stat uniqueness proposition be moved to normative parts?

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

Relationships

Aardvark Mark IV