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 4:08 PM
> To: MiNT List
> Subject: Re: [MiNT] MiNTLib 0.52.3b
>
>
> Hi!
>
> On Fri, Aug 06, 1999 at 03:40:44PM +0200, Julian Reschke wrote:
> > I don't see that a major issue as there are only 3..4
> filesystems that are
> > affected (outside the kernel...).
>
> I don't like the idea, because this IMO is something not to be handled
> by the filesystem. Or are you happy about MagiC's XFS interface that
> makes the filesystem responsible for almost everything (parsing a path,
> checking access restrictions, ...)? ;)

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 :-)

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...

> While thinking about it: another possible solution could be to "hack"
> f_xattr() for that. E.g., on each filesystem's init(), a cookie (or
> better: just the index value) of its root directory would be saved for
> later reference (only if 0 <= dev < 32). In f_xattr(), one would then
> compare the referenced cookie's index field to the corresponding (i.e.
> dev-matching) saved entry, and on a match the hidden flag would be
> added.

Hmm, this would restrict the solution just to "standard" drives, for some
XFSses it couldn't work...

> One problem would still remain, though: GNU-ls cares a sh*t about GEMDOS
> attributes, so the drive entries hidden by this method would still
> appear in the output of ls /. This might be different for your
> (Julian's) ls.

In that case the "problem" can be resolved even easier by renaming U:\a to
U:\.a, correct?