|Anonymous | Login||2022-09-25 08:02 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0000083||[1003.1(2008)/Issue 7] Base Definitions and Headers||Objection||Error||2009-06-29 10:11||2013-04-16 13:06|
|Organization||The Open Group|
|Final Accepted Text||Note: 0000180|
|Summary||0000083: requirements for pathnames beginning with 2 slashes are too loose|
OBJECTION Enhancement Request Number 6
gwc:xxxxxxxxxxxxx Defect in XBD 4.12 (rdvk# 1)
[gwc pathname res 2slash] Tue, 21 Apr 2009 10:02:08 +0100
The description of Pathname Resolution says that a pathname beginning
with two successive <slash> characters may be interpreted in an
implementation-defined manner. This is too loose, as it means applications
cannot portably manipulate such pathnames in the normal way. For example
it is very common for applications to concatenate a directory name, a
slash (if the directory name does not end with one), and a filename in
order to open a file within the directory. Given that the meaning of
"//xyz/dir" and "//xyz/dir/file" are both implementation-defined, there
is no guarantee that "//xyz/dir/file" refers to a file located in the
directory "//xyz/dir", but there should be.
In practice, currently and historically, as far as I'm aware the only
implementations that have had a special meaning for pathnames
beginning with two slashes have all treated the first component after
the leading slashes as the name of a networking resource, and resolved
subsequent components in the normal way. Therefore it is only the first
component that the standard needs to say is interpreted in an
"A pathname that begins with two successive <slash> characters may
be interpreted in an implementation-defined manner, although ..."
"If a pathname begins with two successive <slash> characters, the
first component following the leading <slash> characters may be
interpreted in an implementation-defined manner, although ..."
edited on: 2009-10-12 05:30
The standard is unclear on this issue, and no conformance
distinction can be made between alternative implementations based
on this. This is being referred to the sponsor.
Notes to the Editor (not part of this interpretation):
Make the change suggested by the submitter
IBM's z/OS resolves //pathname requests to MVS datasets (as opposed to the hierarchical filesystem (HFS)) and thus is an example of an implementation that does not interpret the first component of such paths as a network resource. Additionally, z/OS would not accept or recognize additional "directory" or "file" components appended to such paths.
For example, //MY.CATALOG(DATASET)/file does not make sense on z/OS.
[This response to Note: 0000191 was sent to the mailing list, but is worth recording here.]
> IBM's z/OS resolves //pathname requests to MVS datasets (as opposed to the
> hierarchical filesystem (HFS)) and thus is an example of an implementation
> that does not interpret the first component of such paths as a network
> resource. Additionally, z/OS would not accept or recognize additional
> "directory" or "file" components appended to such paths.
> For example, //MY.CATALOG(DATASET)/file does not make sense on z/OS.
I don't see how that affects the proposed change to the standard.
Since stat() or ls -Lld on //MY.CATALOG(DATASET) would show that it
is not a directory (nor a symlink to a directory), applications should
not expect to be able to append additional pathname components to it.
|2009-06-29 10:11||geoffclare||New Issue|
|2009-06-29 10:11||geoffclare||Status||New => Under Review|
|2009-06-29 10:11||geoffclare||Assigned To||=> ajosey|
|2009-06-29 10:11||geoffclare||Name||=> Geoff Clare|
|2009-06-29 10:11||geoffclare||Organization||=> The Open Group|
|2009-06-29 10:11||geoffclare||Section||=> 4.12|
|2009-06-29 10:11||geoffclare||Page Number||=> 112|
|2009-06-29 10:11||geoffclare||Line Number||=> 3040|
|2009-06-29 10:12||geoffclare||Tag Attached: real bug in aardvark|
|2009-06-29 10:13||geoffclare||Status||Under Review => Interpretation Required|
|2009-06-29 10:13||geoffclare||Resolution||Open => Accepted|
|2009-08-06 15:52||Don Cragun||Tag Detached: real bug in aardvark|
|2009-08-06 15:54||ajosey||Note Added: 0000180|
|2009-08-06 18:15||tahonermann||Note Added: 0000191|
|2009-08-11 16:35||Don Cragun||Interp Status||=> Pending|
|2009-09-17 06:52||tahonermann||Issue Monitored: tahonermann|
|2009-09-17 15:41||nick||Interp Status||Pending => Proposed|
|2009-09-22 10:41||geoffclare||Note Added: 0000236|
|2009-10-12 05:30||ajosey||Note Edited: 0000180|
|2009-10-12 05:30||ajosey||Interp Status||Proposed => Approved|
|2009-10-12 05:30||ajosey||Final Accepted Text||=> Note: 0000180|
|2010-09-20 09:23||geoffclare||Tag Attached: tc1-2008|
|2012-02-09 17:24||eblake||Relationship added||related to 0000541|
|2013-04-16 13:06||ajosey||Status||Interpretation Required => Closed|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|