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 structures. 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.) _______________________________________________ Libcdio-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/libcdio-devel
