--uxuisgdDHaNETlh8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 26, 2005 at 01:10:23AM +0200, Reinoud Zandijk wrote:
> On Sat, Jul 09, 2005 at 11:00:01PM -0700, Bill Studenmund wrote:
> > On Sat, Jul 09, 2005 at 01:18:37PM +0200, Hubert Feyrer wrote:
> > I think a cleaner way to handle this is how a number of other OSs do it=
.=20
> > If you have a file that is also a container (an archive file), they can=
=20
> > mount said file. When I download image files on my MacOS X laptop, they=
=20
> > show up as other disks on the desktop.
> >=20
> > I'm not against the idea of us mounting such a file system on top of th=
e=20
> > container file. However that strikes me as a very different semantic fr=
om=20
> > cd'ing into a normal file. :-)
>=20
> i'd rather go without mounting; then permissions, mountpoints etc get in=
=20
> the way for easy acceess.

How do mountpoints get in the way? I can see how permissions could, but=20
once we tackle the issue of turning a user-supplied file into kernel=20
vnodes, then auto-mouning a file system (or simple-request-to-mount) won't=
=20
be a problem.

> Propably a VOP_LOOKUP `overload' like syncfs and friends could, when aske=
d=20
> for VOP_LOOKUP of a name on a VREG file, check for common archive formats=
=20
> and automatically insert ustarfs or whatever its called.
>=20
> Idea?

I don't like it. :-)

1) Big issue is that if we aren't using mount points, then the "ustarfs"=20
has to be wedged into each file system. So we have to teach "ustarfs"=20
to ffs, and lfs, and ext2fs, and msdosfs, and hfs (soon), and ntfs, and=20
nfs, and afs, and coda, and cd9660fs, and anything else we have.

With mount points, we have only one "ustarfs" or "stuffitfs" or "zipfs",=20
and it works with every file system.

2) If you want the tarfs or whatever mounted, you should have to ask for=20
it. Otherwise, I can foresee all sorts of strange issues related to the=20
auto-expansion. Consider downloading a file. Say you started to download,=
=20
failed, and are trying to download again. You open "foo.tgz". The kernel=20
notices it's a .tgz and mounts tarfs on top. The kernel hopefully copes=20
with a partial download. You then go to write the new download. All hell=20
breaks lose, or you can't download.

I think this would be a case where automagic mounting/processing will NOT=
=20
help.

3) Any such file system will have to be much more robust than our current=
=20
file systems. I think we can solve this issue, but the main thing is that=
=20
we will now readily be permitting user data to be turned into kernel=20
structures. So mal-formed archives could be a huge DOS attack. Right now,=
=20
most file systems call panic() if they wander into the weeds. We certainly=
=20
don't want it to be easy for a user archive to do that. :-)

However as I said, I think we can solve that issue. :-)

Take care,

Bill

--uxuisgdDHaNETlh8
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFDDorgWz+3JHUci9cRAvOBAJwMYytpp3op8kRsBZsd6I7MN0c2xwCggJUq
cq/sLdLti776dmWiu2BcmQg=
=4QnY
-----END PGP SIGNATURE-----

--uxuisgdDHaNETlh8--