View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001169 | 1003.1(2016/18)/Issue7+TC2 | System Interfaces | public | 2017-11-10 15:19 | 2024-06-11 09:09 |
| Reporter | geoffclare | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Clarification Requested |
| Status | Closed | Resolution | Accepted | ||
| Name | Geoff Clare | ||||
| Organization | The Open Group | ||||
| User Reference | |||||
| Section | ftruncate() | ||||
| Page Number | 980 | ||||
| Line Number | 33327 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | |||||
| Summary | 0001169: Redundant statement that ftruncate() fails on directories | ||||
| Description | The ftruncate() description says:If fildes refers to a directory, ftruncate() shall fail. This statement is redundant because directories can't be opened for writing and there is already an error specified for file descriptors that are not open for writing. The presence of the statement just causes confusion as to what value errno can be set to when both of the conditions "fildes refers to a directory" and "fildes is not open for writing" are true (since the former does not appear in the ERRORS section). | ||||
| Desired Action | Change:If fildes refers to a directory, ftruncate() shall fail.to: If fildes is a file descriptor open for writing and refers to a file that is neither a regular file nor a shared memory object, the result is unspecified. | ||||
| Tags | tc3-2008 | ||||
|
|
I don't see that as completely redundant as I remember some discussion about some systems allow accessing directory data as writable files, historically or as a privileges sensitive extension, and this special case is consistent with truncate() requiring EISDIR to be returned for the same circumstance. As I read it, the standard doesn't block completely the possibility of ftruncate() being passed a handle opened for rw+ without privileges too, it just doesn't make it easy, on a conforming implementation. If anything, I'd prefer EISDIR be added to ftruncate() shall fail errors instead, separate from EBADF (the one that applies now). An application may want to ignore failures on directories, yet abort if failure occurs on other file types if just looping through all the names in a directory, as usage example. |
|
|
The ftruncate() and truncate() functions used to be described on the same page. This statement about directories on the ftruncate() page is simply some left-over text from the combined page which should have been removed when the split into separate pages was made. The proposed new text is in keeping with POSIX.1b-1993 which said at the top of page 128, "If the file is not a regular file or a shared memory object, the result is unspecified." With regard to implementations having some way of obtaining a writable file descriptor for a directory as an extension, as soon as an application makes use of that extension none of the requirements in the standard apply to any uses of that file descriptor, and so specifying an EISDIR error for ftruncate() would be pointless. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-11-10 15:19 | geoffclare | New Issue | |
| 2017-11-10 15:19 | geoffclare | Name | => Geoff Clare |
| 2017-11-10 15:19 | geoffclare | Organization | => The Open Group |
| 2017-11-10 15:19 | geoffclare | Section | => ftruncate() |
| 2017-11-10 15:19 | geoffclare | Page Number | => 980 |
| 2017-11-10 15:19 | geoffclare | Line Number | => 33327 |
| 2017-11-10 15:19 | geoffclare | Interp Status | => --- |
| 2017-11-11 17:11 | shware_systems | Note Added: 0003879 | |
| 2017-11-13 09:55 | geoffclare | Note Added: 0003880 | |
| 2019-02-04 16:23 | Don Cragun | Status | New => Resolved |
| 2019-02-04 16:23 | Don Cragun | Resolution | Open => Accepted |
| 2019-02-04 16:23 | Don Cragun | Tag Attached: tc3-2008 | |
| 2019-11-08 10:30 | geoffclare | Status | Resolved => Applied |
| 2024-06-11 09:09 | agadmin | Status | Applied => Closed |
