With a Linux-based kernel, GNU ls -i can list the wrong inode
for a mount point.
Ian Jackson raised this issue two years ago with
http://bugs.debian.org/369822, and Wayne Pollock reported it
last week via http://bugzilla.redhat.com/453709
FYI, now, I'm planning to make GNU ls work around what may
Thanks to the prod from Wayne Pollock,
I've just revived this thread:
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/14020
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
In http://bugzilla.redhat.com/454261, Piotr Gackiewicz
reported a bug whereby 'who -a's "+/-" indicator of whether
a user/tty is accepting messages was incorrectly listed as "+",
when in fact, the user was not accepting messages (mesg no).
The difference lay in the group name associated with the P
Ian Jackson <[EMAIL PROTECTED]> wrote:
> Jim Meyering writes ("making GNU ls -i (--inode) work around the linux
> readdir bug"):
>> With a Linux-based kernel, GNU ls -i can list the wrong inode
>> for a mount point.
>>
>> Ian Jackson raised this issue two years ago with
>> http://bugs.debian.org/
Ian Jackson <[EMAIL PROTECTED]> wrote:
> Jim Meyering writes ("Re: making GNU ls -i (--inode) work around the linux
> readdir bug"):
>> Ian Jackson <[EMAIL PROTECTED]> wrote:
>> > That is to say you are proposing to fix my complaint by entrenching
>> > the thing I was complaining about.
>>
>> Yes,
Jim Meyering <[EMAIL PROTECTED]> wrote:
> Ian Jackson <[EMAIL PROTECTED]> wrote:
>> It's the permitted by the specs
>
> The old POSIX spec permitted anything.
> The soon-to-be-current version of POSIX has new wording:
>
> The value of the structure's d_ino member shall be set to the file
>
Jim Meyering writes ("making GNU ls -i (--inode) work around the linux readdir
bug"):
> With a Linux-based kernel, GNU ls -i can list the wrong inode
> for a mount point.
>
> Ian Jackson raised this issue two years ago with
> http://bugs.debian.org/369822, and Wayne Pollock reported it
> last wee
Jim Meyering writes ("Re: making GNU ls -i (--inode) work around the linux
readdir bug"):
> Ian Jackson <[EMAIL PROTECTED]> wrote:
> > That is to say you are proposing to fix my complaint by entrenching
> > the thing I was complaining about.
>
> Yes, but only on a system where readdir- and lstat-
Jim Meyering writes ("Re: making GNU ls -i (--inode) work around the linux
readdir bug"):
> Ian Jackson <[EMAIL PROTECTED]> wrote:
> > That is all systems. All UN*X systems since the dawn of time have
> > behaved this way.
>
> Just because everyone does it doesn't make it right.
In fact, since
On Mon, 7 Jul 2008, Jim Meyering wrote:
> Ian Jackson <[EMAIL PROTECTED]> wrote:
> >
> > That is all systems. All UN*X systems since the dawn of time have
> > behaved this way.
>
> Just because everyone does it doesn't make it right.
Er, are you programming for Unix or not?
> Being fast and inac
On Mon, 7 Jul 2008, Ian Jackson wrote:
>
> When files are only in a single filesystem the inum is sufficient to
> uniquely identify a file. But when we consider more than one
> filesystem, the inum and device are needed together because inums on
> different filesystems are unrelated and may be (of
Andreas,
My point is new line is a non printable character and if I do not remember all
the stuff like echo does prints a new line character, I will be mislead.
Anyway, it is an ideological discussion how to interpret it but I thank you and
the GNU team for prompt response and being at top of t
James,
First, I thank you and the GNU team for being prompt and for being at
the top of the issues. Second new line is a non printable character and
users will not always remember that. By reading the description I
thought new line counts are printed separately not included in character
counts (pr
How about just comparing the GID of the other user's terminal against
the GID of the terminal whose name would have been printed if we'd run
"tty"?
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Tony Finch <[EMAIL PROTECTED]> writes:
> Also, readdir(3) is not the only part of POSIX that needs clarifying.
I participated in the discussion that resulted in this new d_ino
wording being added to POSIX, and my recollection is that the common
behavior where readdir returns the inode number of t
"James Youngman" <[EMAIL PROTECTED]> wrote:
> How about just comparing the GID of the other user's terminal against
> the GID of the terminal whose name would have been printed if we'd run
> "tty"?
Thanks, but in http://bugzilla.redhat.com/454261,
the example shows that a user in the "mesg n" stat
16 matches
Mail list logo
