Re: [Libcdio-devel] UDF status (with implications to libiso9660, GNU fileutils, etc.)

[Steven M. Schultz]

On Sun, 30 Oct 2005, R. Bernstein wrote:

Hi -

> In ISO 9660 and UDF there are a number of structures which handle
> things like files and directories, permissions and attributes
> regarding them. Much information is similar to the information that an
> OS (especially an POSIX-like OS) provides about files and directories.

        Is "similar" good enough?  My concern is that once past the
        easy to map similarities the code's going to turn into a quagmire
        of exceptions - i.e. UDF is POSIX-like _except_ for this attribute,
        that attribute, and so on (...like in XA indicating whether a file 
        is read as Mode 1 or Mode 2 ...).

> So it seems natural to convert the UDF or ISO 9660 specific objects
> into more POSIX-like objects and try to use existing libraries (like
> the standard C library) for working with those.

        It's tempting, that's for sure ;)  

        Not sure, other than the 'pretty printing', how much more will be
        directly useful.

        At some point greater than 32bit filesizes were added weren't they?
        Basic ISO9660 is 32bit only - but I thought I read about 64bit
        extensions (might just be my faulty memory though ;)).

> information. And for this if you look at GNU fileutils, there is a
> library routine modestring() in libfetish.a that takes a mode_t and

        Hmm, systems which aren't necessarily "GNU fileutils" based would
        need local substitutes - not hard but something to keep in mind.

> well. The fact that there's other information that's not covered by
> the mode_t is okay because either there's some other POSIX-like
> structure where this will fit, or in some cases where information
> really is specific to UDF (e.g. a partition number), we can give a an
> access routine to that and provide a routine to give one of the UDF

        The exceptions begin to grow in number.  Wonder how many there will
        end up being  ;)

> Going further in libudf, I'm now thinking of trying to fill out a stat
> structure as is generally found in <sys/stat.h>. Again it may be that
> some fields may have bogus values like "device", and "inode", but the

        They might be "bogus" but they might have 'meaning'.   I'm not sure
        what 'mkisofs' puts there.

        One thing I've seen that is supported but not handled well is the
        concept of hard links.  'mkisofs' (later versions do implement 
        UDF support - not sure what level though) does the right thing - the
        problem comes with 'cp', 'tar' expecting 'link count' and not checking
        the datafields in the UDF structure to detect that two files are the
        same.

> Two related advantages of an approach like this.  First, this kind of
> interface may be already fairly familiar among folks who work with
> POSIX files/directories. And since things are similar, it might be

        True, it has the advantage of similarity and thus familiarity.  That 
        could have the 'down side' of

> easier to extend existing tools which use POSIX files/directories
> (e.g. "ls", and "tar").

        Hmmm, 'ls' and 'tar' and others would need some extra work I think
        to handle the case of hardlinks.  I don't think the "POSIX"/UNIX 
        concept of 'link count' exists.

> Thoughts? Comments?

        Sounds good.  I just felt like rambling a bit about things which
        probably don't matter a whole lot ;)

        Cheers,
        Steven Schultz