[openbeos] Re: ISO-9660 BFS filesystem extension
- From: François Revol <revol@xxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 09 Jan 2002 22:51:48 +0100 (MET)
Well, I had thoughts about this the other day...
I think we even won't have to change mkisofs if we use standards (hidden) files
to store attributes in them, that a modified iso9660 driver would understand
and map attributes from.
We could put them in each folder in BEOSATTR.DAT or something,
and place a BEOSINDX.DAT in the root dir to hold all the indexes.
thoses files could be creates by a special command 'isoindex', placed in the
folders, then we would mkisofs on the result.
that way we could have plain iso9660 mp3 CDs readable even on portable mp3
cdplayers, though still having all the indexing we did on it before burning :)
I'd like to do it, but since I have lots of other projects (including OBOS :^))
maybe someone could do it ?
a startpoint would be
file:///boot/optional/sample-code/add-ons/iso9660/ :)
About UDF... yeah that sounds nice, but does it support indexing too ?
En réponse à "Gelatt, Christopher" <gelattc@xxxxxxxx>:
> Hmmm. Perhaps this isn't the place to propose this, but I'm thinking
> that
> perhaps some extensions to the ISO-9660 specification can be
> implemented, to
> allow for BFS file attributes and filenames in an ISO-9660 track (it's
> nice
> to pop in a CD and have, say, all the audio clips on it have metadata
> available in the Tracker). I know that I could just burn the disc as a
> BFS
> disc, but occasionally, I have to use discs with other operating
> systems.
>
> The Joliet, Rock Ridge, and HFS extensions have worked quite well for
> other
> operating systems and filesystems, especially since you can create
> hybrid
> CDs with more than one filesystem extension used on the same track.
> This
> could probably be implemented on the creation side with an mkisofs
> modification, and (hopefully) on the client side with a filesystem
> plugin,
> preferably to have BeOS recognize these extensions as native BFS
> partitions/tracks.
>
> Regards,
> --Chris Gelatt
>
>
Other related posts:
