RE: [MiNT] MiNTLib 0.52.3b

["Julian Reschke" <reschke@muenster.de>]

> From: owner-mint@fishpool.com [mailto:owner-mint@fishpool.com]On Behalf
> Of Thomas Binder
> Sent: Friday, August 06, 1999 5:02 PM
> To: MiNT List
> Subject: Re: [MiNT] MiNTLib 0.52.3b
>
>
> Hi!
>
> On Fri, Aug 06, 1999 at 04:15:04PM +0200, Julian Reschke wrote:
> > No, I'm not. The only reason why there is a MagiC version of
> SPIN is that
> > Andreas Kromke has done the dirty work for me :-)
>
> Just a question in that context: Is the SPIN! code itself independet of
> the surrounding filesystem interface, i.e. is it only a matter of some
> #defines for you to either compile a MiNT or a MagiC version?

Actually, SPIN consists of a CD-FS library which implements all the ISO, HFS
and audio CDFS related functions. It publishes a very generic interface
(only suited for read-only devices). This library can be linked to three
different wrappers, a very light one for MiNT, another slightly bigger one
for MagiC, and then even another one for a MetaDOS style DOS driver (which
has not been released yet).

> > But just to make sure I understand the issue: each filesystem
> would have to
> > support Fattrib on the root cookie? Doesn't sound like a big deal...
>
> No, the filesystem would have to add the hidden-flag to the attr-field
> in the XATTR-structure it fills in its getxattr(). Of course, this would
> mean there had to be some way for the filesystem to ask the kernel
> whether it should do that, depending on what filesystems the user
> doesn't want to see.

Ahem? I would think that the Fattrib() call which is made to set the hidden
flag at some points trickles down into the filesystem (for it's root
cookie). The filesystem would have to store this flag somewhere, and would
have to return the right value everytime it is asked (using getxattr()).

> > Hmm, this would restrict the solution just to "standard"
> drives, for some
> > XFSses it couldn't work...
>
> Of course. But AFAIR, the original intention was to just hide
> filesystems that usually appear as drive letters in U:\ But it wouldn't
> be too much of a problem to extend my proposition to handle all
> filesystem roots.
>
> > In that case the "problem" can be resolved even easier by
> renaming U:\a to
> > U:\.a, correct?
>
> That's already been suggested, but for some reason those who cried
> loudest for getting rid of GEMDOS drives didn't accept this simple
> solution (can't remember the exact reason, maybe because they are not
> really gone this way, but that would also hold true for my
> f_xattr()-proposition).

I'd say that "those who cried loudest" should try this now, and then we
discuss all this again next week :-)