View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000256 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2010-05-20 20:00 | 2013-04-16 13:06 |
| Reporter | eblake | Assigned To | ajosey | ||
| Priority | normal | Severity | Objection | Type | Omission |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Eric Blake | ||||
| Organization | Red Hat | ||||
| User Reference | ebb.fpathconf | ||||
| Section | fpathconf | ||||
| Page Number | 886 | ||||
| Line Number | 29502 | ||||
| Interp Status | Approved | ||||
| Final Accepted Text | 0000256:0000427 | ||||
| Summary | 0000256: fpathconf unclear on effect of mount points | ||||
| Description | The standard is ambiguous on the behavior of [f]pathconf in the presence of mount points. One interpretation is that when querying a characteristic of all files within a directory, the returned value applies only to the file system containing the directory where the query was made, and excludes any mount points to other devices. By this interpretation, an implementation can give a definitive answer for pathconf("/",_PC_PATH_MAX) that will be smaller than pathconf("/usr",_PC_PATH_MAX), where /usr is a mount point to a file system with support for larger names. But it is also possible to interpret the current standard as stating that pathconf("/",_PC_PATH_MAX) must return the maximum value among all the mount points on the system that occur beneath the listed directory, even though the particular device for "/" cannot support things that large. Implementation-wise, it is much more efficient to return characteristics of a single device than it is to query all possible mount points located as subdirectories of the specified location. Also, given that the whole point of pathconf is that some values are file-system dependent, it is more intuitive that a value returned is for a particular file system, rather than for all possible file systems currently mounted in subdirectories. The standard has text that somewhat supports the intuitive reading, such as line 29597 in the Rationale: "A process may not always be able to generate a name that long and use it if a subdirectory in the pathname crosses into a more restrictive file system." Also, line 29606 documents the volatility of pathconf results over remounts. However, nothing in the normative wording clarifies that the intuitive stance is mandated. The standard already gives a definitive definition of mount point, at line 1994, which can be used to clarify the normative intent. Name length (_PC_NAME_MAX, _PC_PATH_MAX) may vary by directory location within a single mount point (consider the NTFS system, which has a hard limit that an absolute path cannot exceed 32k; on Cygwin 1.7, _PC_PATH_MAX is typically 4k, but will be less than 4k on directories whose absolute name is within 4k of the 32k limit). But other limits, like _PC_CHOWN_RESTRICTED and _PC_PIPE_BUF, are typically consistent for the entire device, regardless of depth in the directory hierarchy. The proposed change for 3 and 5 is therefore slightly different than that for 7 and 9. | ||||
| Desired Action | At line 29506, change: 3. If path or filedes refers to a directory, the value returned shall apply to filenames within the directory. to: 3. If path or filedes refers to a directory, the value returned shall apply to filenames within the directory that would reside on the same mount point. At line 29510, change: 5. If path or fildes refers to a directory, the value returned shall be the maximum length of a relative pathname when the specified directory is the working directory. to: 5. If path or fildes refers to a directory, the value returned shall be the maximum length of a relative pathname that would reside on the same mount point when the specified directory is the working directory. At line 29513, change: If path or fildes refers to a directory, the value returned shall apply to any FIFO that exists or can be created within the directory. to: If path or fildes refers to a directory, the value returned shall apply to any FIFO that exists or can be created within the same mount point of the directory. At line 29517, change: 7. If path or fildes refers to a directory, the value returned shall apply to any files, other than directories, that exist or can be created within the directory. to: 7. If path or fildes refers to a directory, the value returned shall apply to any files, other than directories, that exist or can be created within the same mount point of the directory. At line 29521, change: 9. If path or fildes refers to a directory, the value returned shall be the maximum length of the string that a symbolic link in that directory can contain. to: 9. If path or fildes refers to a directory, the value returned shall be the maximum length of the string that a symbolic link in the same mount point of that directory can contain. At line 29597, after: A process may not always be able to generate a name that long and use it if a subdirectory in the pathname crosses into a more restrictive file system. insert a new sentence: Conversely, a longer name may be possible for a pathname that crosses into a more permissive file system. | ||||
| Tags | tc1-2008 | ||||
|
|
On reflection, I think that most of these changes are not right. Currently pathconf() can return different values for different directories. There is no requirement that it returns the same value for all directories within a particular file system. When a value returned for a directory applies to files within the directory, then note 7 should apply. This note specifically says "other than directories" because the value could be different for a subdirectory, even one that isn't a mount point. Although it appears that there is a problem with note 3, the problem is not in the wording of the note, it is in the use of that note for _PC_FILESIZEBITS. Before _PC_FILESIZEBITS was added, note 3 only appeared on _PC_NAME_MAX and _PC_NO_TRUNC. When note 3 says "filenames" it really does mean the _names_. I believe the appropriate fix is to change _PC_FILESIZEBITS to have note 7 instead of note 3. I think the only note that needs to change to account for mount points is note 5. |
|
|
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): ------------------------------------------------------- At line 29481 change "3,4" to "4,7". At line 29510, change: 5. If path or fildes refers to a directory, the value returned shall be the maximum length of a relative pathname when the specified directory is the working directory. to: 5. If path or fildes refers to a directory, the value returned shall be the maximum length of a relative pathname that would not cross any mount points when the specified directory is the working directory. |
|
|
Comments/objections on the proposed interpretation are due by 31 Aug 2010 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-05-20 20:00 | eblake | New Issue | |
| 2010-05-20 20:00 | eblake | Status | New => Under Review |
| 2010-05-20 20:00 | eblake | Assigned To | => ajosey |
| 2010-05-20 20:00 | eblake | Name | => Eric Blake |
| 2010-05-20 20:00 | eblake | Organization | => Red Hat |
| 2010-05-20 20:00 | eblake | User Reference | => ebb.fpathconf |
| 2010-05-20 20:00 | eblake | Section | => fpathconf |
| 2010-05-20 20:00 | eblake | Page Number | => 886 |
| 2010-05-20 20:00 | eblake | Line Number | => 29502 |
| 2010-05-21 15:32 | geoffclare | Note Added: 0000419 | |
| 2010-06-03 15:45 | geoffclare | Note Added: 0000427 | |
| 2010-06-03 15:46 | geoffclare | Interp Status | => Pending |
| 2010-06-03 15:46 | geoffclare | Final Accepted Text | => 0000256:0000427 |
| 2010-06-03 15:46 | geoffclare | Status | Under Review => Interpretation Required |
| 2010-06-03 15:46 | geoffclare | Resolution | Open => Accepted As Marked |
| 2010-07-30 09:26 | ajosey | Interp Status | Pending => Proposed |
| 2010-07-30 09:26 | ajosey | Note Added: 0000505 | |
| 2010-09-03 06:22 | ajosey | Interp Status | Proposed => Approved |
| 2010-09-24 16:05 | geoffclare | Tag Attached: tc1-2008 | |
| 2013-04-16 13:06 | ajosey | Status | Interpretation Required => Closed |
