On Thu, Jul 13, 2000 at 07:27:55PM -0400, Olivier Galibert wrote:
> On Fri, Jul 14, 2000 at 01:07:38AM +0200, Marcus Brinkmann wrote:
> > On Thu, Jul 13, 2000 at 07:01:28PM -0400, Olivier Galibert wrote:
> > > Currently the on-disk structures for translators in ext2 allow for an
> > > inode to be both a passive translator and a file (or directory) with
> > > actual contents. AFAICT, this capability is not used anywhere for
> > > now. I'm not even sure it is accessible from the filesystem
> > > interface.
> >
> > The underlying node is accessible to the translator, and this can and will
> > be used for example for filter (or for example for activity logging etc).
>
> But only the translator has access to it? That's yucky. This means
> that things can be hidden behind a translator and the only way for
> both yourself and the sysadmin to know what's there is to remove it?
Of course. That's how it is supposed to work after all. I am not sure though
if there is the possibility to write a Hurd-specific tool which can
investigate below the current translator setting (note that translators can
be stacked, too). This is beyond my understanding of the Hurd file system
interfaces.
> It's probably even too magic for the translator itself. This does not
> work:
> dd if=/dev/zero of=dummy bs=1024k count=8
> mke2fs dummy
> settrans -c dummy /hurd/ext2fs `pwd`/dummy
>
> ...because the translator will end up looping on itself.
Maybe this is a bug, but more likely it is a missing feature :)
The ext2fs should use the underlying node to access the file content instead
to access the file through the standard file interface (glibc).
The way to access the underlying node is a bit different than accessing a
file through glibc (the udnerlying node is passed to the translator at start
up).
How about fixing that and submitting a patch?
> > > My question is, do we really need this capability, or would a on-disk
> > > implementation of translators which would use the same allocation
> > > scheme as files (or symlinks, probably) would be ok? That would
> > > remove the block pointer in osd1 and only use one bit in the inode
> > > flags to say "this is a translator".
> >
> > Well, I think it is a useful feature and will be used (maybe optionally) in
> > translators. I have some ideas about it. It's the same in Linux, btw. You
> > can set mount point on existing directories with real content. Disallowing
> > this would inconvenience the users, too.
>
> Under linux a mountpoint is the equivalent of an _active_ translator,
> not a passive one. I have nothing against active translators over,
> well, mostly whatever.
The only difference is that a passive translator is used to start up the
active translator if there is none automatically at first access. They
should not behave differently apart from that.
I agree it takes a little to get used to. But if not abused, the translator
concept is very elegant. From the Hurd ref doc:
Be prudent with these translators: you may accidentally injure people
who want their filesystems to be rigidly tree-structured.(1)
---------- Footnotes ----------
(1) You are lost in a maze of twisty little filesystems, all
alike....
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
[EMAIL PROTECTED], [EMAIL PROTECTED] PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
