Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
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
Reporter geoffclare View Status public  
Assigned To ajosey
Priority normal Resolution Accepted  
Status Closed  
Name Geoff Clare
Organization The Open Group
User Reference
Section 4.12
Page Number 112
Line Number 3040
Interp Status Approved
Final Accepted Text Note: 0000180
Summary 0000083: requirements for pathnames beginning with 2 slashes are too loose
Description  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
 implementation-defined manner.
Desired Action  Change

     "A pathname that begins with two successive <slash> characters may
     be interpreted in an implementation-defined manner, although ..."

 to

     "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 ..."
Tags tc1-2008
Attached Files

- Relationships
related to 0000541Closedajosey pathname resolution of a symlink containing exactly // 

-  Notes
(0000180)
ajosey (manager)
2009-08-06 15:54
edited on: 2009-10-12 05:30

 Interpretation response
------------------------
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.
Rationale:
-------------
None.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------

Make the change suggested by the submitter
(0000191)
tahonermann (reporter)
2009-08-06 18:15

 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.
(0000236)
geoffclare (manager)
2009-09-22 10:41

 [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.

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker