|Anonymous | Login||2018-12-15 23:53 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001169||[1003.1(2016)/Issue7+TC2] System Interfaces||Objection||Clarification Requested||2017-11-10 15:19||2017-11-13 09:55|
|Organization||The Open Group|
|Final Accepted Text|
|Summary||0001169: Redundant statement that ftruncate() fails on directories|
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).
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||No tags attached.|
|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.
|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|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|