libmount.a / cygmount.dll (was 'Mount table in registry')

["Nikolaus Schmitt" <n dot schmitt at scaet dot de>]

Corinna, Igor, Larry:

> On Thu, 22 May 2003, Corinna Vinschen wrote:
> ... Use mount.  Never rely on the registry.

> At 08:12 2003-05-22, Igor Pechtchanski wrote:
> ...  Would making a libmount.a (or, better yet, cygmount.dll) be a good
> idea?  Then programs can link against it and be guaranteed that they can
> read mounts or verify mount locations.  I know Cygwin exports
> getmntent() and the like, but the above would be something that doesn't
> depend on cygwin1.dll. Setup.exe could then use it as well (although
> then it'd have to be a static lib).

> On Thu, 22 May 2003, Randall R Schulz wrote:
> 1) I believe this is probably a good idea.
>
> 2) I think that questions about and interest in the current mount table
> implementation details (registry entries, at the moment) are not
> inappropriate. Sometimes knowing these details is important for
> diagnostic and repair purposes. After all, registry corruption is not
> unheard-of under Windows, is it? Sometimes manual correction could be
> required, at least in principal.
>
> I agree people should not be encouraged, explicitly or implicitly, to
> fiddle with the Windows registry, but many Cygwin users are
> knowledgeable enough to do so without undue probability of committing a
> gross error. In those rare cases where manual intervention in the
> Cygwin portion of the registry _is_ called for, good information on how
> it's used is important.
>
> By the way, isn't direct access to the registry the only way to modify
> or set the heap-chunk-in-megabytes entry?
>

1) In addition to the arguments for not to use the registry for mount table
entries:

Currently, i can not use cygwin on a couple of W2K systems, since their
registry has been locked against write access for anyone except domain
admins. The aren't either allowed to change registry settings on the fly.
The number of cygwin users is very small, thus preparing cygwin installation
for use within a central software installation system would be far too
expensive. The discussion of the very reasons for this locking policies is
useless - i'm not in a role to change it.

2) Did anyone started any efforts to implement a kind of "libmount.a"?

3) Implementation suggestion:
In my opinion, cygwin's "carrier system" should point to the "root
location". Cygwin should be able to use that information to fetch
"/etc/fstab" and "/etc/mtab" for information on further mounts. A cygwin
session could hold the current mounts in its process environment. A mount
table state change could (easily?) be signalled to all current sessions.

The carrier system's pointer to the root location could be achieved by a
registry entry (as it is now), and also by an environment variable - for
example "CYGWIN_ROOT". If none of them are available on startup of
"setup.exe", the program should ask the installing user for the root
location. It should also ask, wether the "root location pointer" should be
established system wide or per user (HKLM / HKCU). All other mounts should
get mantained by "/etc/mtab". Any cygwin program accesses the virtual
filesystem using "cygwin1.dll" - it would control the program session's
mount table using the "root location pointer", "/etc/mtab" and "libmount.a".

Pro's:
 - Enables hassle free usage and installation even on "secured systems".
 - Obsoletes registry usage
 - "Registry mounts" usage would be possible, either.

Con's:
 - some work to do.
 - i'm not as familiar with the cygwin development environment, as needed
   to implement a solution.
 - time.








--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/