Re: Weird problem with RHEL5 isofs driver when using mkisofs -x --exclude options

[Bill Davidsen <davidsen@tmr.com>]

Joerg Schilling wrote:
> Giulio Orsero <giulioo@gmail.com> wrote:
>
>   
> > isoinfo output was always right (at least as for permissions and timestamp
> > which I was interested in).
> >     
>
> isoinfo displayed wrong timestamps for "." and ".." with the old mkisofs clone 
> that comes with RedHat. 
>
> isoinfo still displayes wrong timestamps for "." even with a recent mkisofs.
>
>
>   
> > The incorrect permissions/timestamp were from "ls -l" on the iso image as
> > mounted on linux using Linux isofs driver.
> >
> > That very same iso image, when mounted on Linux, would:
> > - show uncorrect perms/timestamp if mounted on RHEL5
> > - show correct perms/timestamp if mounted on RHEL3
> >     
>
> The incorrect perms are a result of the bugs in the mkisofs version that comes 
> with Redhat.
>
> The fact that you see different timestamps is a result of the fact that ISO-9660
> stores different meta data for dir/ and dir/. 
> If mkisofs does not make sure that the related meta data is identical, you see 
> the known issues.
>
>   
> > If I produce the iso image using "-find"; then Linux isofs RHEL5 driver will
> > show correct perms/timestamp too.
> >     
>
> see above
>
>   
> > My problem is that I have a backup script that when run on RHEL5 will
> > produce iso image which RHEL5 will read in a wrong way, unless it seems I
> > change the backup script to use "-find".
> >
> > What is weird for me is:
> > 1) Why would RHEL5 isofs driver be confused by an iso image produced by
> > mkisofs with the "-x" flag, even when the -x flag should have no effect
> > since, as per my example, would exclude something is not there.
> > As soon as I take the -x option out, RHEL5 will read the iso image
> > correctly.
> > I'd think mkisofs would produce the very same output if I tell it to exclude
> > something that is not there, basically a noop.
> >     
>
> They did change the filesystem implementation in the kernel.
>
>   
> > 2) Switching to "mkisofs -find" seems to fix the issue, but I don't
> > understand why.
> >     
>
> because mkisofs then stores the same meta data for dir/ and dir/. and you see 
> the same values regardless of which values are taken by the FS in the kernel.
>
> In general, your problem suffers from two reasons:
>
> 1)	The filesystem does not return ".". and ".." first with readdir()
>
>   
I believe that this may be a result of the loop mount. However, (a) I 
don't see the part of SuS which promises that these directory entries 
will be returned first, and (b) it appears that "." need not be the 
inode of the current directory.

The behavior of "dir" "dir/" and "dir/." is not the same in cases of 
symbolic links and (it seems) special mounts such as bind and loop. I'm 
not ready to explain in depth, I just observe...
> 2)	The deprecated -x option incorrectly excludes "." and ".."
>
> Please check again with the following patch, it should then work even without 
> -find:
>
>   

Thank you for the patch.

--
Bill Davidsen <davidsen@tmr.com>
 "Woe unto the statesman who makes war without a reason that will still
 be valid when the war is over..." Otto von Bismark