View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001314 | 1003.1(2016/18)/Issue7+TC2 | Base Definitions and Headers | public | 2020-01-05 11:19 | 2024-06-11 09:08 |
| Reporter | dannyniu | Assigned To | |||
| Priority | normal | Severity | Comment | Type | Clarification Requested |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | DannyNiu/NJF | ||||
| Organization | |||||
| User Reference | |||||
| Section | <sys/stat.h> | ||||
| Page Number | Rationale | ||||
| Line Number | Paragraphs 5 and 6. | ||||
| Interp Status | --- | ||||
| Final Accepted Text | 0001314: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 | ||||
|
|
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. |
|
|
Perhaps, in light of 0001314: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. |
|
|
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. |
|
|
Re 0001314: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. |
|
|
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. |
|
|
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. |
| 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 | => 0001314: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 |
