Subject: Re: cd into file [was: Re: CVS commit: src]
To: None <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 08/25/2005 20:22:08
Content-Type: text/plain; charset=us-ascii
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=
> > If you have a file that is also a container (an archive file), they can=
> > mount said file. When I download image files on my MacOS X laptop, they=
> > show up as other disks on the desktop.
> > I'm not against the idea of us mounting such a file system on top of th=
> > container file. However that strikes me as a very different semantic fr=
> > cd'ing into a normal file. :-)
> i'd rather go without mounting; then permissions, mountpoints etc get in=
> 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=
be a problem.
> Propably a VOP_LOOKUP `overload' like syncfs and friends could, when aske=
> for VOP_LOOKUP of a name on a VREG file, check for common archive formats=
> and automatically insert ustarfs or whatever its called.
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,=
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=
3) Any such file system will have to be much more robust than our current=
file systems. I think we can solve this issue, but the main thing is that=
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,=
most file systems call panic() if they wander into the weeds. We certainly=
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. :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----