Richard,
It appears that struct inode i_ino has a special value of 0. I don't
see a mention of that in vfs.txt, and I haven't found anything obvious
in the fs code... Would it be possible to add some documentation of
that, along with an explaination of what i_ino==0 is supposed to
indicate? (Bad/invalid inode?)
TIA,
Eli
--------------------. Real Users find the one combination of bizarre
Eli Carter \ input values that shuts down the system for days.
eli.carter(a)inet.com `-------------------------------------------------
On Thu, 31 Jan 2002, Eli Carter wrote:
> It appears that struct inode i_ino has a special value of 0. I don't
> see a mention of that in vfs.txt, and I haven't found anything obvious
> in the fs code... Would it be possible to add some documentation of
> that, along with an explaination of what i_ino==0 is supposed to
> indicate? (Bad/invalid inode?)
i_ino = 0 is perfectly valid and is in fact one of the system files in
NTFS. And accessing inode 0 from user space works fine, too. The only
thing which is odd is that a simple "ls" (or "ls -l") doesn't show the
file with i_ino=0, while an explicit ls a-la "ls \$MFT" (or "ls -l \$MFT")
does show the file. I believe this to be purely a userspace problem but
when I looked at the /bin/ls source I got scared and ran away... A short
investigation into /bin/ls source didn't make anything obvious appear but
I do think it is /bin/ls at fault and not the kernel...
So I guess my point is that i_ino=0 is not special as far as the kernel is
concerned.
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
Anton Altaparmakov wrote:
>
> On Thu, 31 Jan 2002, Eli Carter wrote:
> > It appears that struct inode i_ino has a special value of 0. I don't
> > see a mention of that in vfs.txt, and I haven't found anything obvious
> > in the fs code... Would it be possible to add some documentation of
> > that, along with an explaination of what i_ino==0 is supposed to
> > indicate? (Bad/invalid inode?)
>
> i_ino = 0 is perfectly valid and is in fact one of the system files in
> NTFS. And accessing inode 0 from user space works fine, too. The only
> thing which is odd is that a simple "ls" (or "ls -l") doesn't show the
> file with i_ino=0, while an explicit ls a-la "ls \$MFT" (or "ls -l \$MFT")
> does show the file. I believe this to be purely a userspace problem but
> when I looked at the /bin/ls source I got scared and ran away... A short
> investigation into /bin/ls source didn't make anything obvious appear but
> I do think it is /bin/ls at fault and not the kernel...
>
> So I guess my point is that i_ino=0 is not special as far as the kernel is
> concerned.
Hmm... 'ls -al' doesn't show the file for me. I was using i_ino=0 for
the root inode, and found that 'ls -al' did not display '.' or '..'. It
very well may be a user-space error... do you know who I should ask
about it?
TIA,
Eli
--------------------. Real Users find the one combination of bizarre
Eli Carter \ input values that shuts down the system for days.
eli.carter(a)inet.com `-------------------------------------------------
At 21:17 31/01/02, Eli Carter wrote:
>Anton Altaparmakov wrote:
> >
> > On Thu, 31 Jan 2002, Eli Carter wrote:
> > > It appears that struct inode i_ino has a special value of 0. I don't
> > > see a mention of that in vfs.txt, and I haven't found anything obvious
> > > in the fs code... Would it be possible to add some documentation of
> > > that, along with an explaination of what i_ino==0 is supposed to
> > > indicate? (Bad/invalid inode?)
> >
> > i_ino = 0 is perfectly valid and is in fact one of the system files in
> > NTFS. And accessing inode 0 from user space works fine, too. The only
> > thing which is odd is that a simple "ls" (or "ls -l") doesn't show the
> > file with i_ino=0, while an explicit ls a-la "ls \$MFT" (or "ls -l \$MFT")
> > does show the file. I believe this to be purely a userspace problem but
> > when I looked at the /bin/ls source I got scared and ran away... A short
> > investigation into /bin/ls source didn't make anything obvious appear but
> > I do think it is /bin/ls at fault and not the kernel...
> >
> > So I guess my point is that i_ino=0 is not special as far as the kernel is
> > concerned.
>
>Hmm... 'ls -al' doesn't show the file for me. I was using i_ino=0 for
>the root inode, and found that 'ls -al' did not display '.' or '..'. It
>very well may be a user-space error... do you know who I should ask
>about it?
<[email protected]> might be a good start...
Or one of the people who wrote it? To quote from the top of ls.c:
----snip----
/* Written by Richard Stallman and David MacKenzie. */
/* Color support by Peter Anvin <[email protected]> and Dennis
Flaherty <[email protected]> based on original patches by
Greg Lee <[email protected]>. */
----snip----
Anton
>TIA,
>
>Eli
>--------------------. Real Users find the one combination of bizarre
>Eli Carter \ input values that shuts down the system for days.
>eli.carter(a)inet.com `-------------------------------------------------
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/