Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001169 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Clarification Requested 2017-11-10 15:19 2019-11-08 10:30
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Accepted  
Status Applied  
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.

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

- Relationships

-  Notes
(0003879)
shware_systems (reporter)
2017-11-11 17:11

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.
(0003880)
geoffclare (manager)
2017-11-13 09:55

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


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker