|Anonymous | Login||2020-01-26 20:30 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001314||[1003.1(2016)/Issue7+TC2] Base Definitions and Headers||Comment||Clarification Requested||2020-01-05 11:19||2020-01-12 03:07|
|Line Number||Paragraphs 5 and 6.|
|Final Accepted Text|
|Summary||0001314: Should file stat uniqueness proposition be moved to normative parts?|
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||No tags attached.|
|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 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.
|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 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
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.
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.
|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|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|