Re: Cdrtools-2.01.01a13 ready with libfind

[misa@redhat.com]

On Fri, Sep 08, 2006 at 03:36:59PM +0200, Joerg Schilling wrote:
> Mihai Ibanescu <misa@redhat.com> wrote:
> 
> > Can you not achieve the same thing with:
> >
> > find <expression> | mkisofs -path-list - <mkisofs-options>
> >
> > I am currently doing that (and manipulating the output of find some more using
> > grep/sed/awk to do graft points etc).
> 
> No, you cannot do things like:
> 
>  mkisofs -o image.iso -R -J -find somedir ( -type d -chown root ) -o -true
> 
> using a separate find command run.
> 
> Also note that future versions of mkisofs will support graft points with
> -find which is also impossible with the method you mention.

True, but can you not achieve the same thing with -uid? :-)

Yes, -uid is sorta global, so you will have all files owned by root. But then 
again you won't be able to have two -find statements in one
invocation, while processing stdin is allowing you to enumerate files with
multiple find statements or anything else you can think of.

As someone pointed out to me, there is a real drawback with the stdin
approach: embedded newlines in filenames. It can be fixed with a -path-list0
(and generate the files with find -print0).

What I was mostly trying to see was, would it not be better to have a way to
pass files (with permissions, owner etc) into mkisofs instead of embedding the
complexity of -find into it?

I know rpm is not necessarily the best example here (hey, we're on a
debian-hosted list :-) but when describing the manifest of files to go into
the archive it uses an (optional) %attr(mode,owner,group) to precede the file
name. Now, I really doubt rpm would handle embedded newlines :-)

So, having a way to pass permission/owner/group/etc within the
file passed in to -path-list0 seems like an interesting approach. I definitely
see the advantage of -find, I am hoping the alternative approach would be more
flexible to more users.

Misa


-- 
To UNSUBSCRIBE, email to cdwrite-REQUEST@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@other.debian.org