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@xxxxxxxxxx> 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@xxxxxxxxxx>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
