From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:60200 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751091AbcDTBr1 (ORCPT ); Tue, 19 Apr 2016 21:47:27 -0400 Subject: Re: Can getdents return zero inode numbers? To: Eric Sandeen , Andreas Dilger References: <56E301BC.9090405@redhat.com> <14BE767D-13C2-4946-B8C7-042654875E05@dilger.ca> <57169980.50803@sandeen.net> Cc: Linux FS Devel From: Florian Weimer Message-ID: <5716DF93.9080207@redhat.com> Date: Tue, 19 Apr 2016 21:46:59 -0400 MIME-Version: 1.0 In-Reply-To: <57169980.50803@sandeen.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 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 > 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