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
0000697 [1003.1(2013)/Issue7+TC1] System Interfaces Comment Clarification Requested 2013-05-15 10:31 2020-08-30 23:44
Reporter steffen View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Steffen Nurpmeso
User Reference
Section none
Page Number none
Line Number none
Interp Status ---
Final Accepted Text
Summary 0000697: Adding of a getdirentries() function
Description POSIX systems don't follow the Unix paradigm "everything is a file" for directories in that it is impossible to simply open(2) a directory and read(2) the descriptor to get access to the list of direntries therein.

In the current POSIX standard there is no way to gain access to directory entries but by using the completely intransparent (in respect to internal resource usage; though today there is now fdopendir(3), but still) and unpredictable ("directory status snapshot") opendir(3) / readdir(3) / closedir(3) family of functions.

On the other hand all (to the best of my knowledge) POSIX systems support some kind of getdents(2), getdirentries(2) or getdirent(2) system call (with, despite their names, almost identical semantics).
This functionality can be used to fully control reading of directory entries, at least in respect to resource usage, and including the possibility to perform bulk reads. A publically accessible example would be [1].

[1] [^]
Desired Action Add a getdirentries(2) function to the standard, to catch up handling of directories with handling of files (e.g., open(2) / getdirentries(2) / close(2) <=> open(2) / read(2) / close(2)).
Or nay.
Tags No tags attached.
Attached Files

- Relationships
related to 0000696New either NAME_MAX shouldn't be optional, or readdir_r() needs clarification 

-  Notes
jilles (reporter)
2013-05-15 22:08

With common implementation methods, all state for objects referenced by file descriptors has to be kept in the kernel (file descriptors may persist across execve() which replaces the userspace memory and may be sent across sockets). I think this should only be forced when there is a benefit to it. I don't see such a benefit here. The getdirentries() function does not make directory file descriptors more interchangeable with other file descriptors because it is specific to directories.

A concrete example of state for a directory stream occurs with stacked union filesystems. The list of directory entries in the union consists of all directory entries in the upper layer and those directory entries in the lower layer that do not match an entry in the upper layer by name. A possible implementation strategy (used in FreeBSD) is to remove the duplicates in opendir() and readdir(). This avoids storing the entire upper directory in the kernel, or reading it repeatedly whenever a block of the lower directory is read. However, an application that calls getdirentries() directly may see duplicates.

A simple solution is to call union filesystems non-compliant but this does not help the real world where people use them and expect applications to cope.
steffen (reporter)
2013-05-16 10:22

Hmm. But this concrete example shows the subtleties of filesystems that are layed upon each other rather than being an objection against getdirentries(2). In fact this is a bit of a pity because i didn't post a function text yesterday and wanted to make it up and use the FreeBSD version of getdirentries(2) since it would allow the most flexible definition that should work out-of-the-box on all systems (despite using off_t not long etc.; and stating that the off_t value is transparent to users).

But when i look at opendir.c (readdir.c) of FreeBSD 10.0 (last modified by your commit b4ce52f6), then it seems that you talk about features at the very first implementation iterations, just fixed so that it at least (?) works.
You use the FreeBSD getdirentries(2) (that luckily exists :) to read in all the entries in case of MNT_UNION or f_fstypename=="unionfs" and loop over that "atomic" snapshot to modify the entries to fixup things that possibly should better be done in the kernel.

Since, well, the current code doesn't even affect readdir(3); i.e., the snapshot from opendir(3) will survive a possibly infinite amount of rewinddir(3) / readdir(3) iterations, without ever being updated!
So, for this to be sane, you need at least some kind of "modification-counter-stamp" interaction with the kernel; that is, imho -- POSIX doesn't seem to state anything about the "freshness" of a DIR* directory stream, today.
... And i don't even know how the stack behaves if the surviving duplicate is removed / moved / whatever, whereas the removed one remains. I.e., it's anyway a snapshot, but it seems to me that the kernel / the union FS must be capable of dealing with it.
There are operating systems which removed all kind of stacked filesystems due to the race that are implied by such implementations. (I don't use them, but could not live without a singly-stacked mount_nullfs(8).)
geoffclare (manager)
2013-05-30 15:57

In the May 30th teleconference we agreed that a function of this type would be a good addition to the standard. New interfaces require a sponsor, but it is possible that the Base Working Group might be willing to do that.

It was felt that none of the three existing functions is a perfect fit for standardization; the favored approach would be to add a new function that has the best features chosen from the three.
geoffclare (manager)
2020-08-28 08:21
edited on: 2020-08-28 08:27

In the Aug 27th teleconference the following proposed changes were agreed to be sufficiently mature to form the basis for a call for sponsorship to The Open Group Base Working Group. There may be further minor changes, particularly in the APPLICATION USAGE for posix_getdents(), before they are considered ready to go into a formal document to be submitted for The Open Group company review.

(Note that the first <dirent.h> change removes XSI shading from d_ino in struct dirent. This shading is already questionable because the readdir() page states an unshaded requirement about how d_ino is set.)
Page and line numbers are for the 2016/2018 edition.
On page 231 line 7773 section <dirent.h>, change:
It shall also define the structure dirent which shall include the following members:
[XSI]<tt>ino_t  d_ino</tt>       File serial number.[/XSI]
     <tt>char   d_name[]</tt>    Filename string of entry.

[XSI]The <dirent.h> header shall define the ino_t type as described in <sys/types.h>.[/XSI]
The array d_name is of unspecified size, but shall contain a filename of at most {NAME_MAX} bytes followed by a terminating null byte.
It shall also define the structure dirent which shall include the following members:
<tt>ino_t  d_ino</tt>       File serial number.
<tt>char   d_name[]</tt>    Filename string of this entry.

and the structure posix_dent which shall include the following members:
<tt>ino_t          d_ino</tt>      File serial number.
<tt>reclen_t       d_reclen</tt>   Length of this entry, including
                                   trailing padding if necessary. See
<tt>unsigned char  d_type</tt>     File type or unknown-file-type indication.
<tt>char           d_name[]</tt>   Filename string of this entry.

The array d_name in each of these structures is of unspecified size, but shall contain a filename of at most {NAME_MAX} bytes followed by a terminating null byte.
The <dirent.h> header shall define the ino_t, reclen_t, and size_t types as described in <sys/types.h>.
The <dirent.h> header shall define the following symbolic constants for the file types and unknown-file-type indicator returned in the d_type member of the posix_dent structure. The values shall be distinct and shall be suitable for use in #if preprocessing directives:
Block special.

Character special.


FIFO special.

Symbolic link.



Unknown file type.

The implementation may implement message queues, semaphores, shared memory objects [TYM]or typed memory objects[/TYM] as distinct file types. The following macros shall be provided to represent these types. The values shall be distinct from each other and from the above symbolic constants beginning with DT_, except when a distinct file type is not implemented, in which case the correponding constant shall have a value that is never returned in d_type by posix_getdents(). The values shall be suitable for use in #if preprocessing directives:
Message queue.


Shared memory object.

Typed memory object.[/TYM]

On page 231 line 7784 section <dirent.h>, add:
int posix_getdents(int, void *, size_t, int);

On page 231 line 7804 section <dirent.h>, add new paragraphs to RATIONALE:
The posix_dent structure was based on existing structures used by traditional getdents() functions, but the name was changed because the existing structures differed in name and in their members. Some used the dirent structure but this is not required to include a d_type member, which is the main advantage of using posix_getdents() over readdir(). The d_reclen member was included, even though some implementations return fixed-length entries and therefore do not need it, as almost all existing code that used getdents() used d_reclen to iterate through the returned entries. Implementations that return fixed-length entries can simply set d_reclen to that length in posix_getdents(). The type reclen_t for d_reclen was introduced, instead of using unsigned short, so as not to create a requirement that {NAME_MAX} cannot be greater than (a value somewhat smaller than) {SHRT_MAX}.
Implementations are encouraged to define a DT_FORCE_TYPE symbolic constant for use in the flags argument to posix_getdents(). See the RATIONALE for [xref to posix_getdents()].

On page 232 line 7810-7812 section <dirent.h>, change:
The array of char d_name is not a fixed size. Implementations may need to declare struct dirent with an array size for d_name of 1, but the actual number of bytes provided matches (or only slightly exceeds) the length of the filename string.
The array of char d_name cannot be assumed to have a fixed size. Implementations may define the d_name array in the dirent and posix_dent structures to have size 1, or size greater than {NAME_MAX}, or use a flexible array member, but in all cases the actual number of characters used for d_name is at least the length of the filename string including the terminating NUL character.

On page 232 line 7814 section <dirent.h>, change FUTURE DIRECTIONS from:
A future version of this standard may add a DT_FORCE_TYPE symbolic constant for use as described in the RATIONALE for [xref to posix_getdents()].

On page 232 line 7817 section <dirent.h>, add posix_getdents() to SEE ALSO.
On page 403 line 13687 section <sys/types.h>, add:
reclen_t Used for directory entry lengths.

On page 403 line 13723 section <sys/types.h>, change:
..., and ino_t shall be defined as unsigned integer types.
..., reclen_t, and ino_t shall be defined as unsigned integer types.

On page 475 line 16318 section 2.2.2 The Name Space, change:
d_, DT_

On page 519 line 18149 section Cancellation Points, add posix_getdents() to the "may" table.
On page 548 line 19289 section 2.12.1 Defined Types, add:
reclen_t Unsigned integer type used for directory entry lengths.

On page 841 line 28511 section fdopendir(), add posix_getdents() to SEE ALSO.
On page 1444 insert a new man page for posix_getdents():

posix_getdents — read directory entries

#include <dirent.h>
int posix_getdents(int fildes, void *buf, size_t nbyte, int flags);

The posix_getdents() function shall attempt to read directory entries from the directory associated with the open file descriptor fildes and shall place information about the directory entries and the files they refer to in posix_dent structures in the buffer pointed to by buf, up to a maximum of nbyte bytes. The number of posix_dent structures populated in buf may be fewer than the number that will fit in nbyte bytes, but shall be at least one if nbyte is greater than or equal to the size of the posix_dent structure plus {NAME_MAX} and fildes is not currently at end-of-file.
The application shall ensure that buf is aligned suitably to point to a posix_dent structure. The alignment needed shall not be more restrictive than the alignment provided by malloc(). Strictly conforming applications shall ensure that the value of flags is zero; other applications can set it to a value constructed by a bitwise-inclusive OR of implementation-defined bitwise-distinct flag values.
Each posix_dent structure returned in buf shall be located at an address that satisfies the implementation's alignment requirements for the posix_dent structure and shall be populated as follows:
  • The value of the d_ino member shall be set to the file serial number of the file named by the d_name member.

  • The value of the d_reclen member shall be set to the number of bytes occupied by this entry in buf, including any padding bytes needed before the next entry.

  • The value of the d_type member shall be set to indicate the file type of the named file, if possible. If the file type can be obtained from the directory entry and is one of the file types defined in this standard, the value shall be DT_BLK, DT_CHR, DT_DIR, DT_FIFO, DT_LNK, DT_REG, DT_SOCK, DT_MQ, DT_SEM, DT_SHM, [TYM]or DT_TMO[/TYM] (see [xref to <dirent.h>]). If it can not be obtained from the directory entry, the value shall be DT_UNKNOWN. If it can be obtained but is not a standard file type, the value shall not equal any of those listed here.

  • The d_name member shall be a filename string, and (if not dot or dot-dot) shall contain the same byte sequence as the last pathname component of the string used to create the directory entry, plus the terminating <NUL> byte.

If the d_name member names a symbolic link, the values of the d_ino and d_type members shall be set to the values for the symbolic link itself.
The posix_getdents() function shall start reading at the current file offset in the open file description associated with fildes. On successful return, the file offset shall be incremented to point to the directory entry immediately following the last entry whose information was returned in buf, or to point to end-of-file if there are no more directory entries. On failure, the value of the file offset is unspecified. The current file offset can be set and retrieved using lseek() on the open file description associated with fildes. The behavior is unspecified if lseek() is used to set the file offset to a value other than zero or a value returned by a previous call to lseek() on the same open file description.
The posix_getdents() function shall not return directory entries containing empty names. If entries for dot or dot-dot exist, a sequence of calls that reads the entire directory shall return one entry for dot and one entry for dot-dot; otherwise, they shall not be returned.
Upon successful completion, posix_getdents() shall mark for update the last data access timestamp of the directory.
If fildes() is a file descriptor associated with a directory stream opened using fdopendir() or opendir(), the behavior is unspecified.

Upon successful completion, either a non-negative integer shall be returned indicating the number of bytes occupied by the posix_dent structures placed in buf or 0 shall be returned indicating the end of the directory was reached without any directory entries being placed in buf. Otherwise, -1 shall be returned and errno shall be set to indicate the error.

The posix_getdents() function shall fail if:
The fildes argument is not a valid file descriptor open for reading.

The nbyte argument is not large enough to contain the information to be returned about the first directory entry read from the directory.

The current file offset is not located at a valid directory entry.

The fildes argument is associated with a non-directory file.

The return value would be greater than {INT_MAX} or one of the values in a structure to be placed in buf cannot be represented correctly.

The posix_getdents() function may fail if:
A physical I/O error has occurred.

Insufficient memory was available to fulfill the request.

This example function lists the files in a specified directory with their file serial number and file type. If the file type is not available from posix_getdents(), it is obtained using fstatat().
#include <dirent.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>
#include <unistd.h>
#define ENTBUFSIZ 10240
int list_dir(const char *dirnam)
    int fd = open(dirnam, O_RDONLY);
    if (fd == -1)
        return -1;
    char *buf = malloc(ENTBUFSIZ);
    if (buf == NULL)
        return -1;
        int nextent = 0;
        int bytesinbuf = posix_getdents(fd, buf, ENTBUFSIZ, 0);
        if (bytesinbuf <= 0)
            return bytesinbuf;
        do {
            const char *ftype;
            struct posix_dent *entp = (void *)&buf[nextent];
            if (entp->d_type == DT_UNKNOWN)
                struct stat stbuf;
                if (fstatat(fd, entp->d_name, &stbuf, 0) == -1)
                    ftype = "?";
                    ftype = S_ISBLK(stbuf.st_mode) ? "b" :
                         S_ISCHR(stbuf.st_mode) ? "c" :
                         S_ISDIR(stbuf.st_mode) ? "d" :
                         S_ISFIFO(stbuf.st_mode) ? "p" :
                         S_ISLNK(stbuf.st_mode) ? "l" :
                         S_ISREG(stbuf.st_mode) ? "r" :
                         S_ISSOCK(stbuf.st_mode) ? "s" :
                         S_TYPEISMQ(&stbuf) ? "mq" :
                         S_TYPEISSEM(&stbuf) ? "sem" :
                         S_TYPEISSHM(&stbuf) ? "shm" :
                         S_TYPEISTMO(&stbuf) ? "tmo" :
                ftype = entp->d_type == DT_BLK ? "b" :
                        entp->d_type == DT_CHR ? "c" :
                        entp->d_type == DT_DIR ? "d" :
                        entp->d_type == DT_FIFO ? "p" :
                        entp->d_type == DT_LNK ? "l" :
                        entp->d_type == DT_REG ? "r" :
                        entp->d_type == DT_SOCK ? "s" :
                        entp->d_type == DT_MQ ? "mq" :
                        entp->d_type == DT_SEM ? "sem" :
                        entp->d_type == DT_SHM ? "shm" :
#ifdef DT_TMO
                        entp->d_type == DT_TMO ? "tmo" :
            printf("%ld\t%s\t%s\n", (long)entp->d_ino, ftype, entp->d_name);
            nextent += entp->d_reclen;
        } while (nextent < bytesinbuf);

If an array of posix_dent structures (needs revising—C99 and later (see says that a struct with a flexible array member cannot be an element of an array) is used to provide the storage for buf in order to satisfy the alignment requirement, it should be noted that the number of array elements used to size the array may bear little or no relation to the number of directory entries that can be stored in it. It is recommended that the number of elements is calculated from the desired size in bytes, for example:
#define DESIREDSIZE 10240
struct posix_dent buf[DESIREDSIZE / sizeof(struct posix_dent) + 1];
size_t nbyte = sizeof buf;

When posix_getdents() is called with a buf that is not type char *, it is important to note that d_reclen is a byte count and therefore any pointer arithmetic involved in calculating the start of the next entry needs to use a char * pointer.
On implementations where directory entries in a directory take up more space than the corresponding posix_dent structures in buf, a call to posix_getdents() may read nbyte bytes from the directory, resulting (in most cases) in the actual number of bytes placed in buf being less than nbyte.
One advantage of posix_getdents() is that it provides the file type of each directory entry (if available), whereas readdir() only does so on implementations that have the file type as a non-standard additional member of the dirent structure. Knowing the file type can greatly reduce the number of fstatat() calls that need to be made when traversing the file hierarchy.
Whether or not a file's type can be obtained from its directory entry may vary across the different file system types supported by an implementation. Therefore applications should not assume that if d_type contains known file types (i.e. not DT_UNKNOWN) for entries in a given directory then it will also contain known file types for entries in subdirectories of that directory.

The posix_getdents() function was derived from existing getdents functions but the name was changed because the existing getdents functions differed in various ways, in particular the type of the second argument (structure pointer or void *), the members of the populated structures, and the error numbers used for some conditions. The name change also provided an opportunity to add a flags argument to provide for future extensibility.
Implementations are encouraged to include support for a DT_FORCE_TYPE flag which, when that bit is set in flags, causes posix_getdents() to look up the file type if it can not be obtained from the directory entry. This will allow applications that need to know the file type of every directory entry to keep the cost of these lookups to the minimum needed to obtain the type at the file system level, without the additional overhead of making a call to fstatat() for every file (that has d_type equal to DT_UNKNOWN).

A future version of this standard may add a DT_FORCE_TYPE flag as described in RATIONALE.

fdopendir(), lseek(), readdir()
XBD <dirent.h>

First released in Issue 8.

On page 1781 line 57632 section readdir(), add posix_getdents() to SEE ALSO.
On page 3791 line 130084 section E.1, add posix_getdents() to the POSIX_FILE_SYSTEM subprofiling group.

shware_systems (reporter)
2020-08-28 17:07

Since NAME_MAX can vary for subdirs that reference file systems other than the root, '/' or "//", I think it is better to characterize the possible length of a posix_dent structure in terms of "as if fpathconf( fd, PC_NAMEMAX ) is used".

Since nbytes is size_t, and maybe should be ofs_t, the function return value should be of the same type.

I think there should be a note about the Return Value, that a value of 0 is possible on a first call, indicating an empty directory on a file system that does not store '.' and '..' entries.

I feel it should also be emphasized if the fd used to access the file is not opened with O_RDWR | O_EXCL only the first call to the interface may be successful. Any additional calls looking for a 0 return may return garbage data due to another thread modifying the directories entries. An alternative is to have buf typed as posix_dent**, which if NULL on entry indicates the interface should malloc() sufficient space for all the records at once.

I would prefer to see the prototype as varargs one, so any flags an implementation defines that require additional arguments have a place for them. For example, a DT_ONLY_TYPE or DT_NOT_TYPE flag would need an additional value to specify which DT_* file type to include or exclude, respectively, from the returned records.

As a wrapper for multiple readdir() calls, conceptually, some might like an additional prototype that uses a DIR * rather than a file descriptor, e.g. posix_fgetdents(DIR *fildes, ...).
kre (reporter)
2020-08-28 17:52

I suspect that the intent of all of this is good, but this one
phrase's wording (wrt the d_name field, it is used for that
field in both struct direct and struct posix_dent):

     but shall contain a filename of at most {NAME_MAX} bytes

is incomprehensible to me. I can read it as saying

     no file names longer than NAME_MAX bytes can ever occur in a d_name
or as
     the d_name field must be able to contain file names at least
     NAME_MAX bytes long

I suspect that the latter is most likely what was intended, but I really
don't know for sure - that one allows implementations to support filesystems
where directories might contain names longer than can be regularly passed to
system calls, for example, and generally allowing implementation extensions
is desirable, but the former allows an application to declare an array of
NAME_MAX+1 bytes and be sure that any d_name entry will fit.

This phrase ought to be reworded to make it clear what is intended there.
Since it is talking about a variable length array, better phrasing would
probably concentrate on what bounds exist for the size of that array, rather
than the length of what might be stored within it.

And while I'm here, I don't think we need to be providing C tutorials,
so I'd drop all the stuff about arrays of posix_dent structures
completely - attempting to write a program using such a thing would be
folly (as it is for any variable sized objects, arrays (in C at least)
require equal sized objects so addresses can be calculated by arithmetic on
the index - the technique to use to handle several dirent or posix_dent
(or anything similar) that are to be combined into a single linear data
struct is the sequence (not a C data type...) where each item follows on
after the one before it, and the only way (without an ancillary data struct)
to locate the N'th item is to examine each of the preceding N-1 in order.
(Network packets are full of this kind of object). But none of this needs
to be in the standard - how to write code is the application programmer's
problem, and text books or "how to" or xxx for dummies, or whatever are
the places where programming techniques belong.
philip-guenther (reporter)
2020-08-28 22:42

I believe all the historical versions of this interface can return entries that did not exist (any longer) and that the caller is expected to skip. At least on the BSDs this has been with entries with d_ino == 0. I believe this had a positive side effect of making readdir() work "more often" after a seekdir() to the position of a file deleted after the telldir(), as the position could remain valid despite the deletion. I take it that this new interface intentionally does not support this and that the implementation is required to only expose valid entries.
philip-guenther (reporter)
2020-08-28 22:52

I think the unspecified nature of the d_name member in the new posix_dent makes writing portable software more difficult while providing only minimal benefit to programs that don't care. I would support requiring it to be a flexible array member and thus eliminating the error of declaring an array and trying to walk it via indexing instead of by advancing a char pointer by d_reclen.

(The unspecified nature of d_name in struct dirent made using readdir_r() unnecessarily painful; thankfully the push to use that API is dead with the wide recognition that readdir() is thread safe on a per-DIR basis, but the memory of that pain lingers.)
shware_systems (reporter)
2020-08-29 11:34
edited on: 2020-08-29 11:41

As written the intent is more the former. The function attempts to pack in to buf as many records as will fit, only adding padding between records to satisfy alignment requirements for accessing the d_inode field of a following record. If ino_t is 64 bits, the d_reclen field will probably be a multiple of 8 to reflect this. In this scenario d_reclen, and the length of the record, may be as low as 16.

To ensure success for the corner case where a filename is the maximum length, the buffer passed in should be at least large enough to hold the maximum size of one of these records, a malloc( sizeof posix_dent + fpathconf(fildes, PC_NAME_MAX) + sizeof ino_t ) should suffice. Normally the buffer will be much larger, however, based on the size reported by a fstatat(fildes, ".") call.

shware_systems (reporter)
2020-08-29 13:07
edited on: 2020-08-29 13:11

Re: 4952
Packing of records does not imply record removal, unless flags are defined for this, such as my suggestions. So, seeing inode values of zero isn't precluded.

The only case I see where this might not hold is if a file system does not report an entry as part of the "file" because it has failed some file system specific validity test. Something like this would be invisible to the implementation, however.

philip-guenther (reporter)
2020-08-30 23:06

The proposed text includes:
    The d_name member shall be a filename string, and (if not dot or dot-dot)
    shall contain the same byte sequence as the last pathname component of the
    string used to create the directory entry, plus the terminating <NUL> byte.

That would seem to require that all returned entries correspond to filenames that existed in the directory at _some_ point in time. However, I see no requirement that posix_getdents() only return currently existing files, nor any requirement that non-existing files be flagged in any way. The former at least seems like an oversight that should be corrected.

I interpret the definition of readdir(), including its description of the DIR type:
    The type DIR, which is defined in the <dirent.h> header, represents a
    directory stream, which is an ordered sequence of all the directory
    entries in a particular directory.
and later text as effectively requiring that readdir() may not return an entry for a file that did not exist at some point between when opendir() or rewinddir() was last called and when readdir() returned it.

Since posix_getdents() is all about bulk transfer with no buffering, I think its description should be updated EITHER to require that
a) all returned entries must have existed at some point during the call, OR
b) all returned entries with d_ino != 0 must have existed at some point during
   the call and specify that entries with d_ino == 0 may have d_name[0] == '\0'

Specifying (b) is more in line with historical BSD behavior, but does require additional application logic, so I'm sympathetic to a view that specifying (a) is the cleaner choice.
philip-guenther (reporter)
2020-08-30 23:11

Oh, and if (b) is chosen and d_ino==0 means an entry that should be skipped, then XBD's entry for "File Serial Number" should be updated to indicate that no file will have a file serial number of zero. (It appears that the standard does not currently reserve that value.)
shware_systems (reporter)
2020-08-30 23:44

For file systems that relate inode values to start sector index, inode 0 is the superblock for that volume, and entirely valid. Saying it is illegal I don't see happening; that code is simply buggy, conceptually. The safer value to use is (ino_t)-1, if it is to be overloaded that way, but defining a DT_DELETED value for d_type is even safer.

- Issue History
Date Modified Username Field Change
2013-05-15 10:31 steffen New Issue
2013-05-15 10:31 steffen Name => Steffen Nurpmeso
2013-05-15 10:31 steffen Section => none
2013-05-15 10:31 steffen Page Number => none
2013-05-15 10:31 steffen Line Number => none
2013-05-15 22:08 jilles Note Added: 0001607
2013-05-16 10:22 steffen Note Added: 0001608
2013-05-30 15:37 eblake Relationship added related to 0000696
2013-05-30 15:57 geoffclare Note Added: 0001629
2014-03-30 00:33 sstewartgallus Issue Monitored: sstewartgallus
2020-08-28 08:21 geoffclare Note Added: 0004947
2020-08-28 08:27 geoffclare Note Edited: 0004947
2020-08-28 17:07 shware_systems Note Added: 0004948
2020-08-28 17:52 kre Note Added: 0004949
2020-08-28 22:42 philip-guenther Note Added: 0004952
2020-08-28 22:52 philip-guenther Note Added: 0004953
2020-08-29 11:34 shware_systems Note Added: 0004955
2020-08-29 11:34 shware_systems Note Added: 0004956
2020-08-29 11:41 shware_systems Note Edited: 0004956
2020-08-29 11:44 shware_systems Note Deleted: 0004955
2020-08-29 13:07 shware_systems Note Added: 0004957
2020-08-29 13:11 shware_systems Note Edited: 0004957
2020-08-30 23:06 philip-guenther Note Added: 0004958
2020-08-30 23:11 philip-guenther Note Added: 0004959
2020-08-30 23:44 shware_systems Note Added: 0004960

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