[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Libcdio-devel] UDF status (with implications to libiso9660, GNU fileuti

From: R. Bernstein
Subject: [Libcdio-devel] UDF status (with implications to libiso9660, GNU fileutils, etc.)
Date: Sun, 30 Oct 2005 04:21:53 -0500

In working on the library for being able to deal with UDF (libudf),
I've come across I guess a issue I that came up with libiso9660 that
in retrospect I don't think I handled well.

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.

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.

Let me give a specific example. There's a libcdio program called
iso-info which largely is like the Unix "ls" command, but for ISO 9660
images. The "ls" command with a "long" listing shows file mode
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
returns a string interpretation of this. (Alas, it would be nice if
modestring were exposed in a public library somewhere.)

So what I've (now) done in libudf is provide a routine that returns a
POSIX mode_t for a UDF file. Internally it gets this information from
two different structures which have lots of other information as
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

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
hope/belief is that there are many routines right now that don't need
that and will do fine with the other information. Likewise I'm
thinking about having a routine to fill out a dirent structure
generally found in <dirent.h> and routines like work like readdir().

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
easier to extend existing tools which use POSIX files/directories
(e.g. "ls", and "tar").

In libiso9660 I had in mind trying to have a stat structure like
<sys/stat>, but for various reasons didn't try to use the full POSIX
structure.  I think part of my problem was not coming to grips with
the fact that there are levels of ISO9660 that just don't have full
POSIX information, and not knowing what to do about the other
non-POSIX-filesystem parts (like in XA indicating whether a file is
read as Mode 1 or Mode 2). Another area in libiso9660 that I now would
like to see redone is in directory reading. Currently libcdio returns
those Cdio-specific list structures. (This was inherited from the way
that vcdimager handled files/directories, but I take full blame in not
adapting when extracting/extending.)

Thoughts? Comments?

(Sorry if this is long. It's been tough to write. And there are other
smaller side issues that I could write about but I think will have to
wait for some other time.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]