Possible bug in ext3 filesystem

Possible bug in ext3 filesystem

[Jens Nie]

Hello List.

I think i found a bug in the ext3 filesystem. It deals with 
dereferencing symlinks. I have installed a fresh openSUSE 10.2 on an
ext3 filesystem.
After that i wanted to include some selfmade LaTeX-classes by creating 
a symlink within /usr/share/texmf/tex/latex to the directory 
containing the class. texhash lists the new link within 
/usr/share/texmf/ls-R. However the complete content of the classes 
directory is missing. File and directory permissions are OK. I suspect 
that the dereferencing of symlinks to the target directory does not 
work on ext3. To check that i tested an older SuSE Installation with 
reiserfs, which works as expected. Another test i made was creating an 
ext3 fs, xfs and reiserfs on a loopback device. Within this test 
filesystem that i mounted temporarily to /mnt i created a symlink to 
/usr. Issuing the command ls -LRa, which is exactly what texhash is 
using and should dereference the link to /usr did not recursively list 
the contents of /usr on the ext3 filesystem whereas it did on the
reiserfs and xfs.

The test system was a dual opteron (x86_64) as well as a mobile Athlon
(i386) system running openSUSE 10.2.

I reported this on the opensuse mailing list first. Someone there was
kind enough to point me directly to this list.

Some more information which might be useful for people not being
directly familiar with opensuse:

- kernel 2.6.18.2 possibly with typical SuSE changes (SuSE release is
2.6.18.2-34-default)
- e2fsprogs 1.39
- coreutils 6.4

Any ideas? Can anyone confirm that this is a bug? Any solutions?

Best Regards

Jens



Jens Nie
Physics
________________________________________________
Phone	+49-591-9136-414
Fax	+49-591-9136-121
JNie@RosenInspection.net
www.RosenInspection.net

RTRC Germany
Am Seitenkanal 8
49811 Lingen (Ems)
GERMANY

Re: Possible bug in ext3 filesystem

[Theodore Tso]

On Thu, Jan 04, 2007 at 12:34:16PM +0100, Jens Nie wrote:
> 
> I think i found a bug in the ext3 filesystem. It deals with 
> dereferencing symlinks. I have installed a fresh openSUSE 10.2 on an
> ext3 filesystem.
> After that i wanted to include some selfmade LaTeX-classes by creating 
> a symlink within /usr/share/texmf/tex/latex to the directory 
> containing the class. texhash lists the new link within 
> /usr/share/texmf/ls-R. However the complete content of the classes 
> directory is missing. File and directory permissions are OK. I suspect 
> that the dereferencing of symlinks to the target directory does not 
> work on ext3. To check that i tested an older SuSE Installation with 
> reiserfs, which works as expected. Another test i made was creating an 
> ext3 fs, xfs and reiserfs on a loopback device. Within this test 
> filesystem that i mounted temporarily to /mnt i created a symlink to 
> /usr. Issuing the command ls -LRa, which is exactly what texhash is 
> using and should dereference the link to /usr did not recursively list 
> the contents of /usr on the ext3 filesystem whereas it did on the
> reiserfs and xfs.

It works for me.  Using Ubuntu Edgy userspace with a 2.6.19-rc3
kernel on a T60p laptop:

						- Ted

Script started on Thu 04 Jan 2007 12:36:43 PM EST
Top-level shell (parent script)
Using ssh-agent pid 6342
<tytso.root@candygram>	{/home/tytso}
499# dd if=/dev/zero of=/var/tmp/test.img bs=1k count=30000
30000+0 records in
30000+0 records out
30720000 bytes (31 MB) copied, 1.28516 seconds, 23.9 MB/s
<tytso.root@candygram>	{/home/tytso}
500# mke2fs -j /var/tmp/test.img
mke2fs 1.40-WIP (14-Nov-2006)
/var/tmp/test.img is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
7520 inodes, 30000 blocks
1500 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=30932992
4 block groups
8192 blocks per group, 8192 fragments per group
1880 inodes per group
Superblock backups stored on blocks: 
	8193, 24577

Writing inode tables: done                            
Creating journal (1400 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 34 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
<tytso.root@candygram>	{/home/tytso}
501# mount -t ext3 -o loop /var/tmp/test.img /mnt
<tytso.root@candygram>	{/home/tytso}
502# cd /mnt
<tytso.root@candygram>	{/mnt}
503# ln -s /tmp foo
<tytso.root@candygram>	{/mnt}
504# ls -l
total 12
 0 lrwxrwxrwx 1 root root     4 2007-01-04 12:38 foo -> /tmp/
12 drwx------ 2 root root 12288 2007-01-04 12:37 lost+found/
<tytso.root@candygram>	{/mnt}
505# ls -LRa /mnt
/mnt:
total 17
 1 ./   4 ../   0 foo/	12 lost+found/

/mnt/foo:
total 33624
    0 ./		      8 IDB46835.DTF	     4 play.pls
    4 ../		     32 IDB66197.DTF	     0 plugtmp/
 6440 APC Flyer_embd.ppt     32 IDB77400.DTF	    56 repair.pdf
26808 dumpe2fs.txt.bz2	     32 IDB78728.DTF	    20 Rt-Issues-1.ods
    0 .esd-15806/	     32 IDB96845.DTF	     0 ssh-CWzKqE6724/
    0 .exchange-tytso/	      0 keyring-hoWMU3/      0 ssh-PtOxzg6309/
    0 gconfd-tytso/	      0 mapping-tytso=	     0 ssh-TnSaM10059/
    0 .gdm_socket=	      0 notesFCB315/	     0 ssh-Zjhueb6724/
    0 .ICE-unix/	      0 orbit-tytso/	     0 ssh-ZueXS10264/
   32 IDB07883.DTF	      4 play-1.pls	     0 virtual-tytso.m02ZFH/
   32 IDB09374.DTF	      4 play-2.pls	     0 .wine-15806/
   32 IDB34926.DTF	      4 play-3.pls	     4 .X0-lock
   40 IDB44293.DTF	      4 play-4.pls	     0 .X11-unix/

/mnt/foo/.esd-15806:
total 0
0 ./  0 ../  0 socket=

/mnt/foo/.exchange-tytso:
total 0
0 ./  0 ../

/mnt/foo/gconfd-tytso:
total 0
0 ./  0 ../  0 lock/

/mnt/foo/gconfd-tytso/lock:
total 4
0 ./  0 ../  4 ior*

/mnt/foo/.ICE-unix:
total 0
0 ./  0 ../  0 6724=

/mnt/foo/keyring-hoWMU3:
total 0
0 ./  0 ../  0 socket=

/mnt/foo/notesFCB315:
total 512
  0 ./	  0 ../  504 ~editclp.ncf    4 ~notetmp.reg    4 ~notetp2.reg

/mnt/foo/orbit-tytso:
total 4
0 ./				    0 linc-1b16-0-7215ae8e714e5=
0 ../				    0 linc-1b38-0-164e0af7b7ab1=
0 bonobo-activation-register.lock*  0 linc-1b7a-0-23ef1182722fa=
4 bonobo-activation-server-ior	    0 linc-1bad-0-510bba9c63bb6=
0 linc-1a44-0-466fcbd5aa1f0=	    0 linc-1bff-0-5f07b0c6e3793=
0 linc-1a92-0-4e186b54931f9=	    0 linc-1c05-0-3427276e3f87c=
0 linc-1aa5-0-1f23e56b70d97=	    0 linc-34e6-0-5853523bb2721=
0 linc-1acc-0-7fbb2ca661716=	    0 linc-4269-0-3a34f2c58b987=
0 linc-1ad1-0-5db9c951c0cc9=	    0 linc-5492-0-d435cecb77c5=
0 linc-1ad4-0-1aac39888363d=	    0 linc-57fc-0-33e090d41719a=
0 linc-1ae6-0-7a50f3e07932f=	    0 linc-f1f-0-68984f4a27444=
0 linc-1ae8-0-684e70a345d5=	    0 linc-f2d-0-68984f4a73a2d=
0 linc-1aea-0-7a50f3e0d46f4=	    0 linc-f2f-0-68984f4a8a1f7=
0 linc-1af4-0-73566ae82dc75=	    0 linc-f31-0-68984f4a91497=
0 linc-1b0d-0-44885fa524551=	    0 linc-f40-0-1f1d2cf4f67e=
0 linc-1b12-0-7215ae8126f2e=

/mnt/foo/plugtmp:
total 0
0 ./  0 ../

/mnt/foo/ssh-CWzKqE6724:
total 0
0 ./  0 ../  0 agent.6724=

/mnt/foo/ssh-PtOxzg6309:
total 0
0 ./  0 ../  0 agent.6309=

/mnt/foo/ssh-TnSaM10059:
total 0
0 ./  0 ../  0 agent.10059=

/mnt/foo/ssh-Zjhueb6724:
total 0
0 ./  0 ../  0 agent.6724=

/mnt/foo/ssh-ZueXS10264:
total 0
0 ./  0 ../  0 agent.10264=

/mnt/foo/virtual-tytso.m02ZFH:
total 0
0 ./  0 ../

/mnt/foo/.wine-15806:
total 0
0 ./  0 ../  0 cxoffice-wine.lock  0 server-802-71e6d9/

/mnt/foo/.wine-15806/server-802-71e6d9:
total 0
0 ./  0 ../  0 lock  0 socket=	0 vwin32.vxd

/mnt/foo/.X11-unix:
total 0
0 ./  0 ../  0 X0=

/mnt/lost+found:
total 13
12 ./   1 ../
<tytso.root@candygram>	{/mnt}
506# 
Script done on Thu 04 Jan 2007 12:38:32 PM EST

Re: Possible bug in ext3 filesystem

[Dave Kleikamp]

On Thu, 2007-01-04 at 12:34 +0100, Jens Nie wrote:
> Hello List.
> 
> I think i found a bug in the ext3 filesystem. It deals with 
> dereferencing symlinks. I have installed a fresh openSUSE 10.2 on an
> ext3 filesystem.
> After that i wanted to include some selfmade LaTeX-classes by creating 
> a symlink within /usr/share/texmf/tex/latex to the directory 
> containing the class. texhash lists the new link within 
> /usr/share/texmf/ls-R. However the complete content of the classes 
> directory is missing. File and directory permissions are OK. I suspect 
> that the dereferencing of symlinks to the target directory does not 
> work on ext3. To check that i tested an older SuSE Installation with 
> reiserfs, which works as expected. Another test i made was creating an 
> ext3 fs, xfs and reiserfs on a loopback device. Within this test 
> filesystem that i mounted temporarily to /mnt i created a symlink to 
> /usr. Issuing the command ls -LRa, which is exactly what texhash is 
> using and should dereference the link to /usr did not recursively list 
> the contents of /usr on the ext3 filesystem whereas it did on the
> reiserfs and xfs.

I did a little playing around with strace and I suspect that it may have
something to do with ext3 returning DT_LNK to the filldir routine (which
gets returned through getdents64).  A lot of file systems always return
DT_UNKNOWN.  Maybe ls is handling the DT_UNKNOWN case alright, but not
the DT_LNK case.  (When DT_UNKNOWN is returned, ls calls stat64() which
would identify the symlink as a directory rather than a symlink.)

> The test system was a dual opteron (x86_64) as well as a mobile Athlon
> (i386) system running openSUSE 10.2.
> 
> I reported this on the opensuse mailing list first. Someone there was
> kind enough to point me directly to this list.
> 
> Some more information which might be useful for people not being
> directly familiar with opensuse:
> 
> - kernel 2.6.18.2 possibly with typical SuSE changes (SuSE release is
> 2.6.18.2-34-default)
> - e2fsprogs 1.39
> - coreutils 6.4
> 
> Any ideas? Can anyone confirm that this is a bug? Any solutions?
> 
> Best Regards
> 
> Jens
-- 
David Kleikamp
IBM Linux Technology Center

Re: Possible bug in ext3 filesystem

[Jan Blunck]

On 1/4/07, Dave Kleikamp <shaggy@linux.vnet.ibm.com> wrote:
> On Thu, 2007-01-04 at 12:34 +0100, Jens Nie wrote:
> > I think i found a bug in the ext3 filesystem. It deals with
> > dereferencing symlinks. I have installed a fresh openSUSE 10.2 on an
> > ext3 filesystem.

No, it seems to be a bug in the coreutils.

> I did a little playing around with strace and I suspect that it may have
> something to do with ext3 returning DT_LNK to the filldir routine (which
> gets returned through getdents64).  A lot of file systems always return
> DT_UNKNOWN.  Maybe ls is handling the DT_UNKNOWN case alright, but not
> the DT_LNK case.  (When DT_UNKNOWN is returned, ls calls stat64() which
> would identify the symlink as a directory rather than a symlink.)

I guess your analysis is right. The problem is that ls only calls
stat() on DT_UNKNOWN entries but it should call it on DT_LNK too.

> > I reported this on the opensuse mailing list first. Someone there was
> > kind enough to point me directly to this list.

They forgot to tell you that not every bug is a kernel bug ;)

I opened a bug in bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=231916