X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: MOUNT.EXE
Date: 23 Sep 2003 12:12:36 GMT
Organization: Aachen University of Technology (RWTH)
Lines: 47
Message-ID: <bkpdbk$c0a$1@nets3.rz.RWTH-Aachen.DE>
References: <7ce56313 DOT 0309220111 DOT 61b9da4a AT posting DOT google DOT com> <bkmils$md3$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <bkp8jo$164d$1 AT ulysses DOT news DOT tiscali DOT de> <u65jjy9g9 DOT fsf AT elta DOT co DOT il>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
X-Trace: nets3.rz.RWTH-Aachen.DE 1064319156 12298 137.226.32.75 (23 Sep 2003 12:12:36 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 23 Sep 2003 12:12:36 GMT
Originator: broeker@
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii <eliz AT elta DOT co DOT il> wrote:

> However, such extensions are private to the program that uses them.
> You cannot easily have a program like `mount' mount some pseudo-device
> and have that device visible in another program, unless you leave
> some record to that effect on disk or something.

Exactly.  Such support essentially has to be integrated with the OS
itself, or it can't be used without causing more grief and confusion
than anything else.

Now, for the purpose of DJGPP programs, our libc already does
hide/emulate large parts of DOS/POSIX, respectively, so it could, in
principle, be extended to handle mount points, too.  I don't think
that's a very good idea, though.  The reason being that we don't have
a sufficiently "central" instance to handle this.

Cygwin tries to do something like this to simulate an even more
Unix-like environment on Win32 than DJGPP does on DOS.  They do have a
'mount' command, whose settings survive reboots by being kept in the
Windows registry.  This is used to provide a Unix-like single-root
tree, and mount the cygwin tool directory as both / and /usr.

They also have a "virtual drive" service that maps all paths of the
form "/cygdrive/d" to the drive letter "d:".  It definitely has its
quirks (e.g. 'ls /cygdrive' will not show up empty, even though 'ls -d
/cygdrive/c' does show that at least one entry exists).  But it works.

The big drawback is that this scheme *only* applies to those programs
built with the Cygwin DLLs, and that they tend to utterly confuse your
average Windows user.

>> Perhaps a mock 'mount' and 'umount'
>> executable could add additional devices and physical directories (even
>> commands) to the DJGPP.ENV....

> It would be a very bad idea IMHO to rewrite DJGPP.ENV to support this
> kind of feature.  It's better to record the info on some other file.

I'm not all that sure about this.  If a feature like Cygwin's were to
be added to DJGPP, then DJGPP.ENV would be the natural place to put
it.  At the very least, DJGPP.ENV would have to hold the name of the
"/etc/mtab" equivalent file, which the libc code would then look into.

-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.