Re: weird bash autocomplete issue

Re: weird bash autocomplete issue

[devzero]

> On Tue, Dec 16, 2008 at 20:37, Roland <devzero@web.de> wrote:
> > i have come across a weird autocomplete issue i assume it is relate=
d to
> > btrfs.
> >
> > let`s have some dirs:
> >
> > /non-btrfs-mount
> >   ./linux
> >   ./testdir
> >
> > /brtfs-mount
> >   ./linux
> >   ./testdir
> >
> > now, if i do "cd t<tab>" in /non-btrfs-mount, "t" autocompletes to =
"testdir"
> > same for l<tab>inux - bash autocompletes as expected.
> >
> > now, the weird thing is, that on /btrfs-mount this behaves differen=
t.
> >
> > autocompletion for testdir works, but not for linux dir. weird.
> >
> > can someone reproduce this ?
>=20
> Open another shell, find the bash process pid of the first shell with=
:
>   ps afx
> and do:
>   strace -p <pid>
> Go back to the first shell, hit <tab>, and the trace should show
> what's going on. You see a significant difference there?


ok, here we go (i hope i did not cut important parts).
i don`t see the real issue, but i did another interesting finding - see=
 below


bad (cd l<tab>):

open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) =3D 3
fstat64(3, {st_dev=3Dmakedev(0, 19), st_ino=3D256, st_mode=3DS_IFDIR|05=
55, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D18, st_atime=3D2008/12/16-21:32:38, st_mtime=3D2008/12/16-=
21:32:37, st_ctime=3D2008/12/16-21:32:37}) =3D 0
getdents64(3, {{d_ino=3D256, d_off=3D2, d_type=3DDT_DIR, d_reclen=3D24,=
 d_name=3D"."} {d_ino=3D256, d_off=3D2, d_type=3DDT_DIR, d_reclen=3D24,=
 d_name=3D".."} {d_ino=3D257, d_off=3D3, d_type=3DDT_DIR, d_reclen=3D24=
, d_name=3D"test"} {d_ino=3D258, d_off=3D9223372036854775807, d_type=3D=
DT_DIR, d_reclen=3D32, d_name=3D"linux"}}, 4096) =3D 104
_llseek(3, 3, [3], SEEK_SET)            =3D 0
getdents64(3, {{d_ino=3D258, d_off=3D9223372036854775807, d_type=3DDT_D=
IR, d_reclen=3D32, d_name=3D"linux"}}, 4096) =3D 32
close(3)                                =3D 0
write(2, "\7", 1)                       =3D 1
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  =3D 0

good (cd t<tab>):

open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) =3D 3
fstat64(3, {st_dev=3Dmakedev(0, 19), st_ino=3D256, st_mode=3DS_IFDIR|05=
55, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D18, st_atime=3D2008/12/16-21:38:13, st_mtime=3D2008/12/16-=
21:38:11, st_ctime=3D2008/12/16-21:38:11}) =3D 0
getdents64(3, {{d_ino=3D256, d_off=3D2, d_type=3DDT_DIR, d_reclen=3D24,=
 d_name=3D"."} {d_ino=3D256, d_off=3D2, d_type=3DDT_DIR, d_reclen=3D24,=
 d_name=3D".."} {d_ino=3D257, d_off=3D3, d_type=3DDT_DIR, d_reclen=3D24=
, d_name=3D"test"} {d_ino=3D258, d_off=3D9223372036854775807, d_type=3D=
DT_DIR, d_reclen=3D32, d_name=3D"linux"}}, 4096) =3D 104
_llseek(3, 3, [3], SEEK_SET)            =3D 0
getdents64(3, {{d_ino=3D258, d_off=3D9223372036854775807, d_type=3DDT_D=
IR, d_reclen=3D32, d_name=3D"linux"}}, 4096) =3D 32
close(3)                                =3D 0
stat64("test", {st_dev=3Dmakedev(0, 19), st_ino=3D257, st_mode=3DS_IFDI=
R|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blo=
cks=3D0, st_size=3D0, st_atime=3D2008/12/16-21:15:29, st_mtime=3D2008/1=
2/16-21:15:29, st_ctime=3D2008/12/16-21:15:29}) =3D 0
stat64("test", {st_dev=3Dmakedev(0, 19), st_ino=3D257, st_mode=3DS_IFDI=
R|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blo=
cks=3D0, st_size=3D0, st_atime=3D2008/12/16-21:15:29, st_mtime=3D2008/1=
2/16-21:15:29, st_ctime=3D2008/12/16-21:15:29}) =3D 0
write(2, "est/", 4)                     =3D 4
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  =3D 0


and now, after adding a file to that dir with "touch abcd", for my curi=
ousity this makes "cd l<tab>" work again.

open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) =3D 3
fstat64(3, {st_dev=3Dmakedev(0, 19), st_ino=3D256, st_mode=3DS_IFDIR|05=
55, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D26, st_atime=3D2008/12/16-21:34:45, st_mtime=3D2008/12/16-=
21:34:44, st_ctime=3D2008/12/16-21:34:44}) =3D 0
getdents64(3, {{d_ino=3D256, d_off=3D2, d_type=3DDT_DIR, d_reclen=3D24,=
 d_name=3D"."} {d_ino=3D256, d_off=3D2, d_type=3DDT_DIR, d_reclen=3D24,=
 d_name=3D".."} {d_ino=3D257, d_off=3D3, d_type=3DDT_DIR, d_reclen=3D24=
, d_name=3D"test"} {d_ino=3D258, d_off=3D17, d_type=3DDT_DIR, d_reclen=3D=
32, d_name=3D"linux"} {d_ino=3D272, d_off=3D9223372036854775807, d_type=
=3DDT_REG, d_reclen=3D24, d_name=3D"abcd"}}, 4096) =3D 128
_llseek(3, 17, [17], SEEK_SET)          =3D 0
getdents64(3, {{d_ino=3D272, d_off=3D9223372036854775807, d_type=3DDT_R=
EG, d_reclen=3D24, d_name=3D"abcd"}}, 4096) =3D 24
close(3)                                =3D 0
stat64("linux", {st_dev=3Dmakedev(0, 19), st_ino=3D258, st_mode=3DS_IFD=
IR|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bl=
ocks=3D0, st_size=3D0, st_atime=3D2008/12/16-21:15:33, st_mtime=3D2008/=
12/16-21:15:33, st_ctime=3D2008/12/16-21:15:33}) =3D 0
stat64("linux", {st_dev=3Dmakedev(0, 19), st_ino=3D258, st_mode=3DS_IFD=
IR|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bl=
ocks=3D0, st_size=3D0, st_atime=3D2008/12/16-21:15:33, st_mtime=3D2008/=
12/16-21:15:33, st_ctime=3D2008/12/16-21:15:33}) =3D 0
write(2, "inux/", 5)                    =3D 5
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  =3D 0


regards
roland


_______________________________________________________________________
T=E4glich 1.000.000 Euro gewinnen! Jetzt kostenlos WEB.DE MillionenKlic=
k=20
spielen! https://millionenklick.web.de/?mc=3Dmail@footer.mklick@home

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: weird bash autocomplete issue

[Kay Sievers]

On Tue, Dec 16, 2008 at 21:46,  <devzero@web.de> wrote:
>> On Tue, Dec 16, 2008 at 20:37, Roland <devzero@web.de> wrote:
>> > i have come across a weird autocomplete issue i assume it is related to
>> > btrfs.
>> >
>> > let`s have some dirs:
>> >
>> > /non-btrfs-mount
>> >   ./linux
>> >   ./testdir
>> >
>> > /brtfs-mount
>> >   ./linux
>> >   ./testdir
>> >
>> > now, if i do "cd t<tab>" in /non-btrfs-mount, "t" autocompletes to "testdir"
>> > same for l<tab>inux - bash autocompletes as expected.
>> >
>> > now, the weird thing is, that on /btrfs-mount this behaves different.
>> >
>> > autocompletion for testdir works, but not for linux dir. weird.
>> >
>> > can someone reproduce this ?
>>
>> Open another shell, find the bash process pid of the first shell with:
>>   ps afx
>> and do:
>>   strace -p <pid>
>> Go back to the first shell, hit <tab>, and the trace should show
>> what's going on. You see a significant difference there?
>
>
> ok, here we go (i hope i did not cut important parts).
> i don`t see the real issue, but i did another interesting finding - see below
>
>
> bad (cd l<tab>):
>
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
> fstat64(3, {st_dev=makedev(0, 19), st_ino=256, st_mode=S_IFDIR|0555, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=18, st_atime=2008/12/16-21:32:38, st_mtime=2008/12/16-21:32:37, st_ctime=2008/12/16-21:32:37}) = 0
> getdents64(3, {{d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."} {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} {d_ino=257, d_off=3, d_type=DT_DIR, d_reclen=24, d_name="test"} {d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, d_name="linux"}}, 4096) = 104
> _llseek(3, 3, [3], SEEK_SET)            = 0
> getdents64(3, {{d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, d_name="linux"}}, 4096) = 32

On Tue, Dec 16, 2008 at 22:26,  <devzero@web.de> wrote:
> i assume it has something to do with the large value for d_off of the last dirent ?

Looks like, 9223372036854775807 is just LLONG_MAX.

Kay

Re: weird bash autocomplete issue

[Kay Sievers]

On Tue, 2008-12-16 at 22:41 +0100, Kay Sievers wrote:
> On Tue, Dec 16, 2008 at 21:46,  <devzero@web.de> wrote:
> >> On Tue, Dec 16, 2008 at 20:37, Roland <devzero@web.de> wrote:
> >> > i have come across a weird autocomplete issue i assume it is related to
> >> > btrfs.
> >> >
> >> > let`s have some dirs:
> >> >
> >> > /non-btrfs-mount
> >> >   ./linux
> >> >   ./testdir
> >> >
> >> > /brtfs-mount
> >> >   ./linux
> >> >   ./testdir
> >> >
> >> > now, if i do "cd t<tab>" in /non-btrfs-mount, "t" autocompletes to "testdir"
> >> > same for l<tab>inux - bash autocompletes as expected.
> >> >
> >> > now, the weird thing is, that on /btrfs-mount this behaves different.
> >> >
> >> > autocompletion for testdir works, but not for linux dir. weird.
> >> >
> >> > can someone reproduce this ?
> >>
> >> Open another shell, find the bash process pid of the first shell with:
> >>   ps afx
> >> and do:
> >>   strace -p <pid>
> >> Go back to the first shell, hit <tab>, and the trace should show
> >> what's going on. You see a significant difference there?
> >
> >
> > ok, here we go (i hope i did not cut important parts).
> > i don`t see the real issue, but i did another interesting finding - see below
> >
> >
> > bad (cd l<tab>):
> >
> > open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
> > fstat64(3, {st_dev=makedev(0, 19), st_ino=256, st_mode=S_IFDIR|0555, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=18, st_atime=2008/12/16-21:32:38, st_mtime=2008/12/16-21:32:37, st_ctime=2008/12/16-21:32:37}) = 0
> > getdents64(3, {{d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."} {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} {d_ino=257, d_off=3, d_type=DT_DIR, d_reclen=24, d_name="test"} {d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, d_name="linux"}}, 4096) = 104
> > _llseek(3, 3, [3], SEEK_SET)            = 0
> > getdents64(3, {{d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, d_name="linux"}}, 4096) = 32
> 
> On Tue, Dec 16, 2008 at 22:26,  <devzero@web.de> wrote:
> > i assume it has something to do with the large value for d_off of the last dirent ?
> 
> Looks like, 9223372036854775807 is just LLONG_MAX.

I can not reproduce that (on openSUSE 11.1). I also don't see
the _llseek() calls.

open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
fstat(3, {st_dev=makedev(0, 18), ...
getdents64(3, {
  {d_ino=260, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."}
  {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."}
  {d_ino=261, d_off=3, d_type=DT_REG, d_reclen=24, d_name="a"}
  {d_ino=262, d_off=4, d_type=DT_REG, d_reclen=24, d_name="b"}
  {d_ino=263, d_off=5, d_type=DT_REG, d_reclen=24, d_name="c"}
  {d_ino=264, d_off=6, d_type=DT_DIR, d_reclen=24, d_name="test"}
  {d_ino=265, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, d_name="linux"}
}, 4096) = 176
getdents64(3, {}, 4096)                 = 0
close(3)                     

This is with today's git kernel and today's standalone btrfs unstable.

You are using the distro kernel and compile the standalone btrfs module?

Kay

Re: weird bash autocomplete issue

[Roland]

> On Tue, 2008-12-16 at 22:41 +0100, Kay Sievers wrote:
>> On Tue, Dec 16, 2008 at 21:46,  <devzero@web.de> wrote:
>> >> On Tue, Dec 16, 2008 at 20:37, Roland <devzero@web.de> wrote:
>> >> > i have come across a weird autocomplete issue i assume it is related 
>> >> > to
>> >> > btrfs.
>> >> >
>> >> > let`s have some dirs:
>> >> >
>> >> > /non-btrfs-mount
>> >> >   ./linux
>> >> >   ./testdir
>> >> >
>> >> > /brtfs-mount
>> >> >   ./linux
>> >> >   ./testdir
>> >> >
>> >> > now, if i do "cd t<tab>" in /non-btrfs-mount, "t" autocompletes to 
>> >> > "testdir"
>> >> > same for l<tab>inux - bash autocompletes as expected.
>> >> >
>> >> > now, the weird thing is, that on /btrfs-mount this behaves 
>> >> > different.
>> >> >
>> >> > autocompletion for testdir works, but not for linux dir. weird.
>> >> >
>> >> > can someone reproduce this ?
>> >>
>> >> Open another shell, find the bash process pid of the first shell with:
>> >>   ps afx
>> >> and do:
>> >>   strace -p <pid>
>> >> Go back to the first shell, hit <tab>, and the trace should show
>> >> what's going on. You see a significant difference there?
>> >
>> >
>> > ok, here we go (i hope i did not cut important parts).
>> > i don`t see the real issue, but i did another interesting finding - see 
>> > below
>> >
>> >
>> > bad (cd l<tab>):
>> >
>> > open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>> > fstat64(3, {st_dev=makedev(0, 19), st_ino=256, st_mode=S_IFDIR|0555, 
>> > st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, 
>> > st_size=18, st_atime=2008/12/16-21:32:38, st_mtime=2008/12/16-21:32:37, 
>> > st_ctime=2008/12/16-21:32:37}) = 0
>> > getdents64(3, {{d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, 
>> > d_name="."} {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, 
>> > d_name=".."} {d_ino=257, d_off=3, d_type=DT_DIR, d_reclen=24, 
>> > d_name="test"} {d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, 
>> > d_reclen=32, d_name="linux"}}, 4096) = 104
>> > _llseek(3, 3, [3], SEEK_SET)            = 0
>> > getdents64(3, {{d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, 
>> > d_reclen=32, d_name="linux"}}, 4096) = 32
>>
>> On Tue, Dec 16, 2008 at 22:26,  <devzero@web.de> wrote:
>> > i assume it has something to do with the large value for d_off of the 
>> > last dirent ?
>>
>> Looks like, 9223372036854775807 is just LLONG_MAX.
>
> I can not reproduce that (on openSUSE 11.1). I also don't see
> the _llseek() calls.

weird. no btrfs issue then !?

>
> open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> fstat(3, {st_dev=makedev(0, 18), ...
> getdents64(3, {
>  {d_ino=260, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."}
>  {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."}
>  {d_ino=261, d_off=3, d_type=DT_REG, d_reclen=24, d_name="a"}
>  {d_ino=262, d_off=4, d_type=DT_REG, d_reclen=24, d_name="b"}
>  {d_ino=263, d_off=5, d_type=DT_REG, d_reclen=24, d_name="c"}
>  {d_ino=264, d_off=6, d_type=DT_DIR, d_reclen=24, d_name="test"}
>  {d_ino=265, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, 
> d_name="linux"}
> }, 4096) = 176
> getdents64(3, {}, 4096)                 = 0
> close(3)
>
> This is with today's git kernel and today's standalone btrfs unstable.
>
> You are using the distro kernel and compile the standalone btrfs module?

yes.
to be honest, i`m slightly newer than 11.1 (did zypper dup to latest factory 
some days ago)

linux:~ # bash -version
GNU bash, version 3.2.39(1)-release (i586-suse-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.


roland

Re: weird bash autocomplete issue

[Kay Sievers]

On Wed, Dec 17, 2008 at 09:45, Roland <devzero@web.de> wrote:
>> On Tue, 2008-12-16 at 22:41 +0100, Kay Sievers wrote:
>>>
>>> On Tue, Dec 16, 2008 at 21:46,  <devzero@web.de> wrote:
>>> >> On Tue, Dec 16, 2008 at 20:37, Roland <devzero@web.de> wrote:
>>> >> > i have come across a weird autocomplete issue i assume it is related
>>> >> > >> > to
>>> >> > btrfs.
>>> >> >
>>> >> > let`s have some dirs:
>>> >> >
>>> >> > /non-btrfs-mount
>>> >> >   ./linux
>>> >> >   ./testdir
>>> >> >
>>> >> > /brtfs-mount
>>> >> >   ./linux
>>> >> >   ./testdir
>>> >> >
>>> >> > now, if i do "cd t<tab>" in /non-btrfs-mount, "t" autocompletes to
>>> >> > >> > "testdir"
>>> >> > same for l<tab>inux - bash autocompletes as expected.
>>> >> >
>>> >> > now, the weird thing is, that on /btrfs-mount this behaves >> >
>>> >> > different.
>>> >> >
>>> >> > autocompletion for testdir works, but not for linux dir. weird.
>>> >> >
>>> >> > can someone reproduce this ?
>>> >>
>>> >> Open another shell, find the bash process pid of the first shell with:
>>> >>   ps afx
>>> >> and do:
>>> >>   strace -p <pid>
>>> >> Go back to the first shell, hit <tab>, and the trace should show
>>> >> what's going on. You see a significant difference there?
>>> >
>>> >
>>> > ok, here we go (i hope i did not cut important parts).
>>> > i don`t see the real issue, but i did another interesting finding - see
>>> > > below
>>> >
>>> >
>>> > bad (cd l<tab>):
>>> >
>>> > open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>>> > fstat64(3, {st_dev=makedev(0, 19), st_ino=256, st_mode=S_IFDIR|0555, >
>>> > st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, > st_size=18,
>>> > st_atime=2008/12/16-21:32:38, st_mtime=2008/12/16-21:32:37, >
>>> > st_ctime=2008/12/16-21:32:37}) = 0
>>> > getdents64(3, {{d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, >
>>> > d_name="."} {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, > d_name=".."}
>>> > {d_ino=257, d_off=3, d_type=DT_DIR, d_reclen=24, > d_name="test"}
>>> > {d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, > d_reclen=32,
>>> > d_name="linux"}}, 4096) = 104
>>> > _llseek(3, 3, [3], SEEK_SET)            = 0
>>> > getdents64(3, {{d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, >
>>> > d_reclen=32, d_name="linux"}}, 4096) = 32
>>>
>>> On Tue, Dec 16, 2008 at 22:26,  <devzero@web.de> wrote:
>>> > i assume it has something to do with the large value for d_off of the >
>>> > last dirent ?
>>>
>>> Looks like, 9223372036854775807 is just LLONG_MAX.
>>
>> I can not reproduce that (on openSUSE 11.1). I also don't see
>> the _llseek() calls.
>
> weird. no btrfs issue then !?
>
>>
>> open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
>> fstat(3, {st_dev=makedev(0, 18), ...
>> getdents64(3, {
>>  {d_ino=260, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."}
>>  {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."}
>>  {d_ino=261, d_off=3, d_type=DT_REG, d_reclen=24, d_name="a"}
>>  {d_ino=262, d_off=4, d_type=DT_REG, d_reclen=24, d_name="b"}
>>  {d_ino=263, d_off=5, d_type=DT_REG, d_reclen=24, d_name="c"}
>>  {d_ino=264, d_off=6, d_type=DT_DIR, d_reclen=24, d_name="test"}
>>  {d_ino=265, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32,
>> d_name="linux"}
>> }, 4096) = 176
>> getdents64(3, {}, 4096)                 = 0
>> close(3)
>>
>> This is with today's git kernel and today's standalone btrfs unstable.
>>
>> You are using the distro kernel and compile the standalone btrfs module?
>
> yes.
> to be honest, i`m slightly newer than 11.1 (did zypper dup to latest factory
> some days ago)
>
> linux:~ # bash -version
> GNU bash, version 3.2.39(1)-release (i586-suse-linux-gnu)
> Copyright (C) 2007 Free Software Foundation, Inc.

That is still the same bash, the one you use is a 32bit version. Do
you run a 32 bit kernel too? I could try that on a 32 bit box then.

Thanks,
Kay

Re: weird bash autocomplete issue

[Chris Mason]

On Wed, 2008-12-17 at 14:59 +0100, Kay Sievers wrote:
> On Wed, Dec 17, 2008 at 09:45, Roland <devzero@web.de> wrote:
> >> On Tue, 2008-12-16 at 22:41 +0100, Kay Sievers wrote:
> >>>
> >>> > open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
> >>> > fstat64(3, {st_dev=makedev(0, 19), st_ino=256, st_mode=S_IFDIR|0555, >
> >>> > st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, > st_size=18,
> >>> > st_atime=2008/12/16-21:32:38, st_mtime=2008/12/16-21:32:37, >
> >>> > st_ctime=2008/12/16-21:32:37}) = 0
> >>> > getdents64(3, {{d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, >
> >>> > d_name="."} {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, > d_name=".."}
> >>> > {d_ino=257, d_off=3, d_type=DT_DIR, d_reclen=24, > d_name="test"}
> >>> > {d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, > d_reclen=32,
> >>> > d_name="linux"}}, 4096) = 104
> >>> > _llseek(3, 3, [3], SEEK_SET)            = 0
> >>> > getdents64(3, {{d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, >
> >>> > d_reclen=32, d_name="linux"}}, 4096) = 32
> >>>
> >>> On Tue, Dec 16, 2008 at 22:26,  <devzero@web.de> wrote:
> >>> > i assume it has something to do with the large value for d_off of the >
> >>> > last dirent ?
> >>>
> >>> Looks like, 9223372036854775807 is just LLONG_MAX.
> >>
> >> I can not reproduce that (on openSUSE 11.1). I also don't see
> >> the _llseek() calls.
> >
> > weird. no btrfs issue then !?
> >
> >>
> >> open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> >> fstat(3, {st_dev=makedev(0, 18), ...
> >> getdents64(3, {
> >>  {d_ino=260, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."}
> >>  {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."}
> >>  {d_ino=261, d_off=3, d_type=DT_REG, d_reclen=24, d_name="a"}
> >>  {d_ino=262, d_off=4, d_type=DT_REG, d_reclen=24, d_name="b"}
> >>  {d_ino=263, d_off=5, d_type=DT_REG, d_reclen=24, d_name="c"}
> >>  {d_ino=264, d_off=6, d_type=DT_DIR, d_reclen=24, d_name="test"}
> >>  {d_ino=265, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32,
> >> d_name="linux"}
> >> }, 4096) = 176
> >> getdents64(3, {}, 4096)                 = 0
> >> close(3)
> >>
> >> This is with today's git kernel and today's standalone btrfs unstable.
> >>
> >> You are using the distro kernel and compile the standalone btrfs module?
> >
> > yes.
> > to be honest, i`m slightly newer than 11.1 (did zypper dup to latest factory
> > some days ago)
> >
> > linux:~ # bash -version
> > GNU bash, version 3.2.39(1)-release (i586-suse-linux-gnu)
> > Copyright (C) 2007 Free Software Foundation, Inc.
> 
> That is still the same bash, the one you use is a 32bit version. Do
> you run a 32 bit kernel too? I could try that on a 32 bit box then.

At least on my 32 bit box, tab completion works fine.  But, the d_off of
LLONG_MAX comes from btrfs_readdir().  Git had a feature where it would
loop infinitely over a directory in some cases and this was my
workaround.

This should be fixed in git by now, so I can drop it if that really is
causing problems in bash.

-chris

Re: weird bash autocomplete issue

[Kay Sievers]

On Wed, Dec 17, 2008 at 15:17, Chris Mason <chris.mason@oracle.com> wrote:
> On Wed, 2008-12-17 at 14:59 +0100, Kay Sievers wrote:
>> On Wed, Dec 17, 2008 at 09:45, Roland <devzero@web.de> wrote:
>> >> On Tue, 2008-12-16 at 22:41 +0100, Kay Sievers wrote:
>> >>>
>> >>> > open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>> >>> > fstat64(3, {st_dev=makedev(0, 19), st_ino=256, st_mode=S_IFDIR|0555, >
>> >>> > st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, > st_size=18,
>> >>> > st_atime=2008/12/16-21:32:38, st_mtime=2008/12/16-21:32:37, >
>> >>> > st_ctime=2008/12/16-21:32:37}) = 0
>> >>> > getdents64(3, {{d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, >
>> >>> > d_name="."} {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, > d_name=".."}
>> >>> > {d_ino=257, d_off=3, d_type=DT_DIR, d_reclen=24, > d_name="test"}
>> >>> > {d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, > d_reclen=32,
>> >>> > d_name="linux"}}, 4096) = 104
>> >>> > _llseek(3, 3, [3], SEEK_SET)            = 0
>> >>> > getdents64(3, {{d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, >
>> >>> > d_reclen=32, d_name="linux"}}, 4096) = 32
>> >>>
>> >>> On Tue, Dec 16, 2008 at 22:26,  <devzero@web.de> wrote:
>> >>> > i assume it has something to do with the large value for d_off of the >
>> >>> > last dirent ?
>> >>>
>> >>> Looks like, 9223372036854775807 is just LLONG_MAX.
>> >>
>> >> I can not reproduce that (on openSUSE 11.1). I also don't see
>> >> the _llseek() calls.
>> >
>> > weird. no btrfs issue then !?
>> >
>> >>
>> >> open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
>> >> fstat(3, {st_dev=makedev(0, 18), ...
>> >> getdents64(3, {
>> >>  {d_ino=260, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."}
>> >>  {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."}
>> >>  {d_ino=261, d_off=3, d_type=DT_REG, d_reclen=24, d_name="a"}
>> >>  {d_ino=262, d_off=4, d_type=DT_REG, d_reclen=24, d_name="b"}
>> >>  {d_ino=263, d_off=5, d_type=DT_REG, d_reclen=24, d_name="c"}
>> >>  {d_ino=264, d_off=6, d_type=DT_DIR, d_reclen=24, d_name="test"}
>> >>  {d_ino=265, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32,
>> >> d_name="linux"}
>> >> }, 4096) = 176
>> >> getdents64(3, {}, 4096)                 = 0
>> >> close(3)
>> >>
>> >> This is with today's git kernel and today's standalone btrfs unstable.
>> >>
>> >> You are using the distro kernel and compile the standalone btrfs module?
>> >
>> > yes.
>> > to be honest, i`m slightly newer than 11.1 (did zypper dup to latest factory
>> > some days ago)
>> >
>> > linux:~ # bash -version
>> > GNU bash, version 3.2.39(1)-release (i586-suse-linux-gnu)
>> > Copyright (C) 2007 Free Software Foundation, Inc.
>>
>> That is still the same bash, the one you use is a 32bit version. Do
>> you run a 32 bit kernel too? I could try that on a 32 bit box then.
>
> At least on my 32 bit box, tab completion works fine.

It works fine here too on 64 bit. I'll try with openSUSE 11.1 on a
32bit box later tonight.

> But, the d_off of
> LLONG_MAX comes from btrfs_readdir().  Git had a feature where it would
> loop infinitely over a directory in some cases and this was my
> workaround.

There are other filesystems doing the same, usually with 32bit int max
instead of 64 bit int max, I guess that should work fine.

> This should be fixed in git by now, so I can drop it if that really is
> causing problems in bash.

I'll come back if I can reproduce it with the same environment Roland is using.

Kay

Re: weird bash autocomplete issue

[Kay Sievers]

On Wed, Dec 17, 2008 at 15:46, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Wed, Dec 17, 2008 at 15:17, Chris Mason <chris.mason@oracle.com> wrote:
>> On Wed, 2008-12-17 at 14:59 +0100, Kay Sievers wrote:
>>> On Wed, Dec 17, 2008 at 09:45, Roland <devzero@web.de> wrote:
>>> >> On Tue, 2008-12-16 at 22:41 +0100, Kay Sievers wrote:
>>> >>>
>>> >>> > open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>>> >>> > fstat64(3, {st_dev=makedev(0, 19), st_ino=256, st_mode=S_IFDIR|0555, >
>>> >>> > st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, > st_size=18,
>>> >>> > st_atime=2008/12/16-21:32:38, st_mtime=2008/12/16-21:32:37, >
>>> >>> > st_ctime=2008/12/16-21:32:37}) = 0
>>> >>> > getdents64(3, {{d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, >
>>> >>> > d_name="."} {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, > d_name=".."}
>>> >>> > {d_ino=257, d_off=3, d_type=DT_DIR, d_reclen=24, > d_name="test"}
>>> >>> > {d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, > d_reclen=32,
>>> >>> > d_name="linux"}}, 4096) = 104
>>> >>> > _llseek(3, 3, [3], SEEK_SET)            = 0
>>> >>> > getdents64(3, {{d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, >
>>> >>> > d_reclen=32, d_name="linux"}}, 4096) = 32
>>> >>>
>>> >>> On Tue, Dec 16, 2008 at 22:26,  <devzero@web.de> wrote:
>>> >>> > i assume it has something to do with the large value for d_off of the >
>>> >>> > last dirent ?
>>> >>>
>>> >>> Looks like, 9223372036854775807 is just LLONG_MAX.
>>> >>
>>> >> I can not reproduce that (on openSUSE 11.1). I also don't see
>>> >> the _llseek() calls.
>>> >
>>> > weird. no btrfs issue then !?
>>> >
>>> >>
>>> >> open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
>>> >> fstat(3, {st_dev=makedev(0, 18), ...
>>> >> getdents64(3, {
>>> >>  {d_ino=260, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."}
>>> >>  {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."}
>>> >>  {d_ino=261, d_off=3, d_type=DT_REG, d_reclen=24, d_name="a"}
>>> >>  {d_ino=262, d_off=4, d_type=DT_REG, d_reclen=24, d_name="b"}
>>> >>  {d_ino=263, d_off=5, d_type=DT_REG, d_reclen=24, d_name="c"}
>>> >>  {d_ino=264, d_off=6, d_type=DT_DIR, d_reclen=24, d_name="test"}
>>> >>  {d_ino=265, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32,
>>> >> d_name="linux"}
>>> >> }, 4096) = 176
>>> >> getdents64(3, {}, 4096)                 = 0
>>> >> close(3)
>>> >>
>>> >> This is with today's git kernel and today's standalone btrfs unstable.
>>> >>
>>> >> You are using the distro kernel and compile the standalone btrfs module?
>>> >
>>> > yes.
>>> > to be honest, i`m slightly newer than 11.1 (did zypper dup to latest factory
>>> > some days ago)
>>> >
>>> > linux:~ # bash -version
>>> > GNU bash, version 3.2.39(1)-release (i586-suse-linux-gnu)
>>> > Copyright (C) 2007 Free Software Foundation, Inc.
>>>
>>> That is still the same bash, the one you use is a 32bit version. Do
>>> you run a 32 bit kernel too? I could try that on a 32 bit box then.
>>
>> At least on my 32 bit box, tab completion works fine.
>
> It works fine here too on 64 bit. I'll try with openSUSE 11.1 on a
> 32bit box later tonight.
>
>> But, the d_off of
>> LLONG_MAX comes from btrfs_readdir().  Git had a feature where it would
>> loop infinitely over a directory in some cases and this was my
>> workaround.
>
> There are other filesystems doing the same, usually with 32bit int max
> instead of 64 bit int max, I guess that should work fine.
>
>> This should be fixed in git by now, so I can drop it if that really is
>> causing problems in bash.
>
> I'll come back if I can reproduce it with the same environment Roland is using.

I see the same issue on x86 32 bit, with the additional __llseek()
between the getdents64(), and the last entry returned by readdir
ignored.

If I change the returned LLONG_MAX to LONG_MAX in inode.c, it all
works fine, and the __llseek() disappears.

Kay

Re: weird bash autocomplete issue

[Chris Mason]

On Wed, 2008-12-17 at 23:15 +0100, Kay Sievers wrote:
> > There are other filesystems doing the same, usually with 32bit int max
> > instead of 64 bit int max, I guess that should work fine.
> >
> >> This should be fixed in git by now, so I can drop it if that really is
> >> causing problems in bash.
> >
> > I'll come back if I can reproduce it with the same environment Roland is using.
> 
> I see the same issue on x86 32 bit, with the additional __llseek()
> between the getdents64(), and the last entry returned by readdir
> ignored.
> 
> If I change the returned LLONG_MAX to LONG_MAX in inode.c, it all
> works fine, and the __llseek() disappears.

Ok, thanks I'll work up a patch.

-chris

Re: weird bash autocomplete issue

[devzero]

> Sure, would be good to have that fixed. Cc: kasievers@novell.com in
> the bug, and I will move it directly to the right guy. :)

ok, just submitted.

https://bugzilla.novell.com/show_bug.cgi?id=3D460560


regards
roland


> -----Urspr=FCngliche Nachricht-----
> Von: "Kay Sievers" <kay.sievers@vrfy.org>
> Gesendet: 19.12.08 02:27:34
> An: devzero@web.de
> CC: "Chris Mason" <chris.mason@oracle.com>,  "linux-btrfs@vger.kernel=
=2Eorg" <linux-btrfs@vger.kernel.org>
> Betreff: Re: weird bash autocomplete issue


> On Fri, Dec 19, 2008 at 01:59,  <devzero@web.de> wrote:
> >> I see the same issue on x86 32 bit, with the additional __llseek()
> >> between the getdents64(), and the last entry returned by readdir
> >> ignored.
> >
> > confirmed - it`s readdir which assumes 32bit.
> >
> > attached is a sample program which shows the issue on my system.
> >
> > if compiled with -D_FILE_OFFSET_BITS=3D64", the problem goes away.
> >
> > old posting from around 2001:
> >
> >>http://sourceware.org/ml/libc-alpha/2001-01/msg00216.html
> >>
> >>This is why everybody will have to compile programs with
> >>_FILE_OFFSET_BITS=3D64.  Did you ever notice that all GNU programs
> >>already do this?
> >
> > as 32bit systems can use 64bit filesystems, i think btrfs is correc=
t and bash is wrong,
> > as it isn`t LFS aware. i think all 32bit stuff should be LFS aware,=
 nowadays.
> >
> > to be exact, it`s not bash but readline library which comes with ba=
sh.
> > bash configure script correctly checks for _FILE_OFFSET_BITS value,=
 but readline configure script doesn`t.
> > this explains why i could not reproduce the issue when i build bash=
 without readline support.
> >
> > does it make sense to file a ticket at novell bugzilla ?
>=20
> Sure, would be good to have that fixed. Cc: kasievers@novell.com in
> the bug, and I will move it directly to the right guy. :)
>=20
> Thanks,
> Kay
>=20


_______________________________________________________________________
Sensationsangebot verl=E4ngert: WEB.DE FreeDSL - Telefonanschluss + DSL
f=FCr nur 16,37 Euro/mtl.!* http://dsl.web.de/?ac=3DOM.AD.AD008K15039B7=
069a

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: weird bash autocomplete issue

[Kay Sievers]

On Fri, Dec 19, 2008 at 01:59,  <devzero@web.de> wrote:
>> I see the same issue on x86 32 bit, with the additional __llseek()
>> between the getdents64(), and the last entry returned by readdir
>> ignored.
>
> confirmed - it`s readdir which assumes 32bit.
>
> attached is a sample program which shows the issue on my system.
>
> if compiled with -D_FILE_OFFSET_BITS=64", the problem goes away.
>
> old posting from around 2001:
>
>>http://sourceware.org/ml/libc-alpha/2001-01/msg00216.html
>>
>>This is why everybody will have to compile programs with
>>_FILE_OFFSET_BITS=64.  Did you ever notice that all GNU programs
>>already do this?
>
> as 32bit systems can use 64bit filesystems, i think btrfs is correct and bash is wrong,
> as it isn`t LFS aware. i think all 32bit stuff should be LFS aware, nowadays.
>
> to be exact, it`s not bash but readline library which comes with bash.
> bash configure script correctly checks for _FILE_OFFSET_BITS value, but readline configure script doesn`t.
> this explains why i could not reproduce the issue when i build bash without readline support.
>
> does it make sense to file a ticket at novell bugzilla ?

Sure, would be good to have that fixed. Cc: kasievers@novell.com in
the bug, and I will move it directly to the right guy. :)

Thanks,
Kay

Re: weird bash autocomplete issue

[devzero]

> I see the same issue on x86 32 bit, with the additional __llseek()
> between the getdents64(), and the last entry returned by readdir
> ignored.

confirmed - it`s readdir which assumes 32bit.

attached is a sample program which shows the issue on my system.

if compiled with -D_FILE_OFFSET_BITS=3D64", the problem goes away.

old posting from around 2001:

>http://sourceware.org/ml/libc-alpha/2001-01/msg00216.html
>
>This is why everybody will have to compile programs with
>_FILE_OFFSET_BITS=3D64.  Did you ever notice that all GNU programs
>already do this?

as 32bit systems can use 64bit filesystems, i think btrfs is correct an=
d bash is wrong,=20
as it isn`t LFS aware. i think all 32bit stuff should be LFS aware, now=
adays.

to be exact, it`s not bash but readline library which comes with bash.
bash configure script correctly checks for _FILE_OFFSET_BITS value, but=
 readline configure script doesn`t.
this explains why i could not reproduce the issue when i build bash wit=
hout readline support.

does it make sense to file a ticket at novell bugzilla ?

regards
roland


linux:/btrfs # ls -ltr
total 13
drwxrwxrwx 1 root root     0 Dec 16 22:44 test
drwxrwxrwx 1 root root  1056 Dec 17 01:10 linux-2.6.27.8-1
drwxr-xr-x 1 root root     0 Dec 17 22:53 abc
drwxr-xr-x 1 root root     0 Dec 19 00:48 bcd
-rw-r--r-- 1 root root   443 Dec 19 01:15 example.c
-rwxr-xr-x 1 root root 10962 Dec 19 01:15 a.out

linux:/btrfs # ./a.out
=2E
=2E.
linux-2.6.27.8-1
test
abc
bcd
example.c
readdir: Value too large for defined data type


regards
roland



#include <stdio.h>
#include <sys/types.h>
#include <dirent.h>
#include <errno.h>
#include <string.h>
#include <stdlib.h>

int main( int argc, char *argv[] ) {
    DIR *pDIR;
    struct dirent *pDirEnt;

    pDIR =3D opendir(".");

    pDirEnt =3D readdir( pDIR );

    while ( pDirEnt !=3D NULL ) {
        printf( "%s\n", pDirEnt->d_name );
        pDirEnt =3D readdir( pDIR );
        if (errno) perror("readdir");

    }

    closedir( pDIR );

}
____________________________________________________________________
Psssst! Schon vom neuen WEB.DE MultiMessenger geh=F6rt?=20
Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3D3123

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: weird bash autocomplete issue

[devzero]

> > linux:~ # bash -version
> > GNU bash, version 3.2.39(1)-release (i586-suse-linux-gnu)
> > Copyright (C) 2007 Free Software Foundation, Inc.
>=20
> That is still the same bash, the one you use is a 32bit version. Do
> you run a 32 bit kernel too? I could try that on a 32 bit box then.
>=20
> Thanks,
> Kay
>=20

yes, all 32bit.=20
_______________________________________________________________________
T=E4glich 1.000.000 Euro gewinnen! Jetzt kostenlos WEB.DE MillionenKlic=
k=20
spielen! https://millionenklick.web.de/?mc=3Dmail@footer.mklick@home

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: weird bash autocomplete issue

[Kay Sievers]

On Tue, Dec 16, 2008 at 20:37, Roland <devzero@web.de> wrote:
> i have come across a weird autocomplete issue i assume it is related to
> btrfs.
>
> let`s have some dirs:
>
> /non-btrfs-mount
>   ./linux
>   ./testdir
>
> /brtfs-mount
>   ./linux
>   ./testdir
>
> now, if i do "cd t<tab>" in /non-btrfs-mount, "t" autocompletes to "testdir"
> same for l<tab>inux - bash autocompletes as expected.
>
> now, the weird thing is, that on /btrfs-mount this behaves different.
>
> autocompletion for testdir works, but not for linux dir. weird.
>
> can someone reproduce this ?

Open another shell, find the bash process pid of the first shell with:
  ps afx
and do:
  strace -p <pid>
Go back to the first shell, hit <tab>, and the trace should show
what's going on. You see a significant difference there?

Kay

weird bash autocomplete issue

[Roland]

hi,

i have come across a weird autocomplete issue i assume it is related to 
btrfs.

let`s have some dirs:

/non-btrfs-mount
    ./linux
    ./testdir

/brtfs-mount
    ./linux
    ./testdir

now, if i do "cd t<tab>" in /non-btrfs-mount, "t" autocompletes to "testdir"
same for l<tab>inux - bash autocompletes as expected.

now, the weird thing is, that on /btrfs-mount this behaves different.

autocompletion for testdir works, but not for linux dir. weird.

can someone reproduce this ?

i`m on opensuse 11.1 with 2.6.27.8-1-default and latest btrfs-unstable from 
git.

regards
roland