Re: Weird problem with RHEL5 isofs driver when using mkisofs -x --exclude options
Giulio Orsero <giulioo@gmail.com> wrote:
> >OK, so the filesystem does not behave as expected on UNIX:
> >
> >If "." and ".." are delivered at all, they come first.
> >
> >In any case, the -find variant of the command line I send you should
> >work. Did you test it?
>
> Sorry, I hadn't seen it, here's the output:
>
> ===========
> mkisofs 2.01.01a42 (i686-pc-linux-gnu) Copyright (C) 1993-1997 Eric
> Youngdale (C) 1997-2008 Jörg Schilling
> Setting input-charset to 'UTF-8' from locale.
> Total translation table size: 0
> Total rockridge attributes bytes: 653
> Total directory bytes: 4096
> Path table size(bytes): 34
> Max brk space used 21000
> 177 extents written (0 MB)
>
> Directory listing of /
> 23 drwxr-xr-x 4 0 0 2048 Jul 9 2008 [ 23 02] .
> 23 drwxr-xr-x 4 0 0 2048 Jul 9 2008 [ 23 02] ..
> 25 drwxr-xr-x 2 0 0 2048 Jan 1 2008 [ 25 02] dir1
> 24 drwxr-xr-x 2 0 0 2048 Jan 1 2008 [ 24 02] dir2
>
> Directory listing of /dir1/
> 25 drwxr-xr-x 2 0 0 2048 Jan 1 2008 [ 25 02] .
> 25 drwxr-xr-x 4 0 0 2048 Jul 9 2008 [ 25 02] ..
>
> Directory listing of /dir2/
> 24 drwxr-xr-x 2 0 0 2048 Jan 1 2008 [ 24 02] .
> 24 drwxr-xr-x 4 0 0 2048 Jul 9 2008 [ 24 02] ..
> total 4
> drwxr-xr-x 2 root root 2048 Jan 1 2008 dir1 <=== CORRECT
> drwxr-xr-x 2 root root 2048 Jan 1 2008 dir2
> =============
So it is obvious that the problems that did remain for you after switching to a
recent original (but without using -find) are an aftereffect of the wrong
readdir() return order of the filenames.
> Now I'm a bit confused.
> The "non working" iso image produced on RHEL5 has correct
> permissions/timestamp if I transfer in on a RHEL3 system.
>
> So, is this a RHEL5 general fs issue or a RHEL5 isofs issue?
>
> Why would the method used my mkisofs matter if isoinfo show the same output?
I don't understand you.
I thought that isoinfo shows the correct output for -find and an incorrect
output if you don't use -find.
In any case, the isoinfo output is important - not the results from a local
filesystem implementation in Linux.
If dir and dir/. have different timestamps, there is a bug in mkisofs.
This is what you get on all current Linux distributions (except for Gentoo if
you select the original software) because the other Linux distributions only
deliver you a mkisofs version that is based on mkisofs-2.01 and that has been
published in September 2004.
The fork delivered by these Linux versions is unmaintained (many reported bugs
remain unfixed since more than a year) and this version has even many
additional bugs that never have been in the original.
I did fix several dozen well known bugs that have been in mkisofs for years.
While the new code with -find (from libfind) that has been introduced in Summer
2006 is based on an implementation that has been independently tested, the
original directory traversal code from Eric Youngdale has the typical quality
of average UNIX code. The old traversal code has the advantage that is is a bit
faster than the -find variant but it suffers from typical hard to catch
marginal-problems. It is (in contrary to to the code from libfind) e.g. not
able to deal with hard linked directories (ot constructs that look similar)
without going into a loop.
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Reply to: