This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 0/2] Squashing long inodes.


On 02/28/2014 03:53 AM, Florian Weimer wrote:
> On 02/27/2014 06:22 PM, Denis Obrezkov wrote:
> 
>> Should it be solved? Should it be solved a different way?
> 
> Replacing out-of-range inode numbers with 0 might be better because
> this seems to be the value applications expect for file systems
> without inodes.  Pretending that you have unique inode values while
> you actually don't seems rather problematic, and there is code out
> there that will break randomly due to this.
> 
> However, glibc should always use stat64 and friends internally, to
> avoid failures on 32-bit systems.  Beyond that, there is little that
> we can do while preserving ABI.

I agree with Florian and Paul here.
 
I do not think that squashing the inode is a safe or useful
semantic to allow.

My strong preference is to keep the code returning EOVERFLOW.

I expect that the code that expects a unique inode
will likely just break in other weird ways if we return an
inode of 0. Thus we've just complicated the interface for
no good reason and avoided the ability to detect the
incompatibility between the application ABI and the filesystem
e.g. EOVERFLOW.

Continuing to support legacy 32-bit applications will get
harder and harder without maintaining the surrounding shell
of 32-bit interfaces. Eventually you'll be running the 32-bit
applications in a VM with a 32-bit kernel and 32-bit filesystem.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]