Re: kern/48797

["Thomas Schmitt" <scdbackup%gmx.net@localhost>]

The following reply was made to PR kern/48797; it has been noted by GNATS.

From: "Thomas Schmitt" <scdbackup%gmx.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/48797
Date: Fri, 09 May 2014 22:30:17 +0200

 Hi,
 
 >  Then let's fix the callers! We have had 64bit inodes for close to 10 years
 > in NetBSD.
 
 But why did nobody notice the rollover in ls -i ?
 
 I already wondered about the lack of PRs about 64 bit inode numbers.
 
 
 Nevertheless, i am forced to agree that my proposal might be too
 risky compared with its benefit.
 
 On the second ISO image which i tested now, i got indication
 that i missed something about symbolic links:
 
   netbsd# ls -l /mnt/libburn-1.3.4/libburn/.libs/libburn.la
 
   ls: /mnt/libburn-1.3.4/libburn/.libs/libburn.la: Invalid argument
   lrwxrwxrwx  1 thomas  dbus  0 Dec 12 12:15 
/mnt/libburn-1.3.4/libburn/.libs/libburn.la
 
 Whereas with only kern/48787 applied:
 
   netbsd# ls -l /mnt/libburn-1.3.4/libburn/.libs/libburn.la
   lrwxrwxrwx  1 thomas  dbus  13 Dec 12 12:15 
/mnt/libburn-1.3.4/libburn/.libs/libburn.la -> ../libburn.la
 
 It is ok too, if i set the shift value to 0. So at least this
 proposed verification of the culprit would work.
 
 I am optimistic that i could find and fix the cause for this
 error message. Probably it's some kind of ino-to-address
 computation.
 But i am less optimistic that this is the only remaining pitfall.
 Much more testing would be needed.
 
 So if you think that this feature is not worth anyway,
 then i retract my proposal, as i lack of strong arguments
 against this opinion.
 
 One could rather use the test image as easy method to expose
 larger-than-32-bit inode numbers for testing purposes.
 
 Sorry for the noise. {:)