View Issue Details

IDProjectCategoryView StatusLast Update
00011691003.1(2016/18)/Issue7+TC2System Interfacespublic2024-06-11 09:09
Reportergeoffclare Assigned To 
PrioritynormalSeverityObjectionTypeClarification Requested
Status ClosedResolutionAccepted 
NameGeoff Clare
OrganizationThe Open Group
User Reference
Sectionftruncate()
Page Number980
Line Number33327
Interp Status---
Final Accepted Text
Summary0001169: Redundant statement that ftruncate() fails on directories
DescriptionThe 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 ActionChange:
If fildes refers to a directory, ftruncate() shall fail.

If fildes refers to any other file type, except a shared memory object, the result is unspecified.
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.
Tagstc3-2008

Activities

shware_systems

2017-11-11 17:11

reporter   bugnote:0003879

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.

geoffclare

2017-11-13 09:55

manager   bugnote:0003880

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.

Issue History

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