Can getdents return zero inode numbers?

Can getdents return zero inode numbers?

[Florian Weimer]

Is it possible that getdents returns a zero inode number for a name
which actually has a file (or directory, device node etc.) behind it?

Thanks,
Florian

Re: Can getdents return zero inode numbers?

[Andreas Dilger]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

On Mar 11, 2016, at 10:34 AM, Florian Weimer <fweimer@redhat.com> wrote:
> 
> Is it possible that getdents returns a zero inode number for a name
> which actually has a file (or directory, device node etc.) behind it?

The d_ino == 0 value is valid to return and means that the filename was
unlinked from the directory but the entry was not actually removed.

I guess if there are files with hard links it is possible that the inode
referenced by the unlinked name may still have other paths referencing it,
or it is possible if there is a race condition (e.g. getdents() returns
a previously deleted name returning d_ino == 0, then a file with the same
name being created).  POSIX doesn't require that readdir()/getdents()
be up-to-date with current file create/unlink state, only when the dirfd
was first opened, or if rewinddir() is called:

   http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir.html

   If a file is removed from or added to the directory after the most
   recent call to opendir() or rewinddir(), whether a subsequent call
   to readdir() returns an entry for that file is unspecified.

Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Can getdents return zero inode numbers?

[Florian Weimer]

On 03/11/2016 10:20 PM, Andreas Dilger wrote:
> On Mar 11, 2016, at 10:34 AM, Florian Weimer <fweimer@redhat.com>
> wrote:
>> 
>> Is it possible that getdents returns a zero inode number for a
>> name which actually has a file (or directory, device node etc.)
>> behind it?
> 
> The d_ino == 0 value is valid to return and means that the filename
> was unlinked from the directory but the entry was not actually
> removed.

Okay, so it makes sense to skip over entries with d_ino == 0.  I found
code in glibc's glob implementation which does that and was a bit
puzzled and worried that there might be Linux file systems which have
zero inode numbers (so that glob would fail on them).

Thanks,
Florian

Re: Can getdents return zero inode numbers?

[Florian Weimer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/11/2016 10:20 PM, Andreas Dilger wrote:
> On Mar 11, 2016, at 10:34 AM, Florian Weimer <fweimer@redhat.com>
> wrote:
>> 
>> Is it possible that getdents returns a zero inode number for a
>> name which actually has a file (or directory, device node etc.)
>> behind it?
> 
> The d_ino == 0 value is valid to return and means that the filename
> was unlinked from the directory but the entry was not actually
> removed.

Thanks.

Which file systems do this?  Is it possible to see this in action?

Florian

Re: Can getdents return zero inode numbers?

[Andreas Dilger]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]


> On Apr 8, 2016, at 12:40 PM, Florian Weimer <fweimer@redhat.com> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 03/11/2016 10:20 PM, Andreas Dilger wrote:
>> On Mar 11, 2016, at 10:34 AM, Florian Weimer <fweimer@redhat.com>
>> wrote:
>>> 
>>> Is it possible that getdents returns a zero inode number for a
>>> name which actually has a file (or directory, device node etc.)
>>> behind it?
>> 
>> The d_ino == 0 value is valid to return and means that the filename
>> was unlinked from the directory but the entry was not actually
>> removed.
> 
> Thanks.
> 
> Which file systems do this?  Is it possible to see this in action?

I suspect that this is mostly or completely a non-issue in Linux, since
all of the directory entries are copied from the filesystem directory
into struct dirent, and ext4 does not return entries with i_ino = 0
back to userspace.

This was more of a problem with older *nix that allowed applications to
read the on-disk directory data directly.  GNU ls has NOT_AN_INODE_NUMBER=0
and treats those dirents specially, but that code is so awfully structured
it is hard to see what it is doing.

Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Can getdents return zero inode numbers?

[Eric Sandeen]

[-- Attachment #1.1: Type: text/plain, Size: 742 bytes --]



On 3/11/16 4:20 PM, Andreas Dilger wrote:
> On Mar 11, 2016, at 10:34 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>
>> Is it possible that getdents returns a zero inode number for a name
>> which actually has a file (or directory, device node etc.) behind it?
> 
> The d_ino == 0 value is valid to return and means that the filename was
> unlinked from the directory but the entry was not actually removed.

Until recently, didn't the filesystems which use get_next_ino() accept
inode 0 as a legit inode number?

commit 2adc376c551943a07170cbe70f43e6d6065f8906
Author: Carlos Maiolino <cmaiolino@redhat.com>
Date:   Thu Jun 25 12:25:58 2015 -0300

    vfs: avoid creation of inode number 0 in get_next_ino

-Eric


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 881 bytes --]

Re: Can getdents return zero inode numbers?

[Florian Weimer]

On 04/19/2016 04:48 PM, Eric Sandeen wrote:
>
>
> On 3/11/16 4:20 PM, Andreas Dilger wrote:
>> On Mar 11, 2016, at 10:34 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>>
>>> Is it possible that getdents returns a zero inode number for a name
>>> which actually has a file (or directory, device node etc.) behind it?
>>
>> The d_ino == 0 value is valid to return and means that the filename was
>> unlinked from the directory but the entry was not actually removed.
>
> Until recently, didn't the filesystems which use get_next_ino() accept
> inode 0 as a legit inode number?

Thanks Eric for unearthing this change.

> commit 2adc376c551943a07170cbe70f43e6d6065f8906
> Author: Carlos Maiolino <cmaiolino@redhat.com>
> Date:   Thu Jun 25 12:25:58 2015 -0300
>
>      vfs: avoid creation of inode number 0 in get_next_ino

As far as I understand it, this does nothing to fix up existing files 
with inode 0, so I filed bugs to fix this in glibc as well:

https://sourceware.org/bugzilla/show_bug.cgi?id=19970
https://sourceware.org/bugzilla/show_bug.cgi?id=19971

We had no idea on the glibc side that this wasn't just a theoretical issue.

Thanks,
Florian