This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[1.7] Alternative root directory. Sort of a regression.


Before I begin, I know this is an "out there" thing to try and do, so
I am steeled for some negative responses.

With 1.7, the cygwin root directory determination is fixed to location
from the path of the loaded cygwin1.dll. However, the 1.7 user guide
details a way to override this behaviour. From

A correct root directory is quite essential to the operation of
Cygwin. A default root directory is evaluated at startup so a fstab
entry for the root directory is not necessary. If it's wrong, nothing
will work as expected. Therefore, the root directory evaluated by
Cygwin itself is treated as an immutable mount point and can't be
overridden in /etc/fstab... unless you think you really know what
you're doing. In this case, use the override flag in the options field
in the /etc/fstab file. Since this is a dangerous thing to do, do so
at your own risk.

This certainly works, but as the method requires correction of the
root directory post (or during) the parse of /etc/fstab, it is not
suitable for forcing the location of the /etc/fstab through an
alternate root directory. In that sense, although I too favour the
fstab method, it is a little less flexible than being able to modify
the appropriate registry keys in 1.5.

There is a workaround, but it's icky (IMO). That would be to move the
cygwin1.dll file to a bin directory at the same path level as the etc
directory you want the alternative fstab read from (copy won't do it,
because the dll will always be loaded from the same directory as the
executable (if I'm not mistaken). It would be up to me then to
manually set the global/user PATH environment variable to allow the
cygwin executables to load this cygwin1.dll.

Other than that the only two thing that I could think to implement,
say if I was inclined to maintain my own customisation, would be:
1) the dead easy re-instatement of some form of registry read for the
root path.
2) the bit harder change to have fstab re-read/parsed once and no more
than once, upon detection of an override of root. I am guessing this
would not be a popular idea?

Any comments/ideas would be appreciated.


-- Problem reports: FAQ: Documentation: Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]