On Wed, Sep 29, 2010 at 11:08:21AM +0200, Derry Shribman wrote:
Hi,
Doesn't the 'noacl' mount option provide that already?
Partially, there are also the ihash and the exec/notexec options. A lot
has been already discussed on the cygwin-patches list, see, for instance
The problem with mount options is that they are 'static'. They require a cygwin
'reboot' and they do not allow 'inheritance' for subprocesses, and do not allow
concurrent processes running in different modes.
Right. Another way of looking at this is that the mount options offer
consistency. The notion of setting an environment variable in Window A
to get one behavior and not settting it in Window B is, IMO, a support
nightmare and a recipe for end-user confusion.
Dynamic options via CYGWIN env allow setting stuff in runtime, in /etc/profile,
~/bashrc, or for specific commands (and their subprocesses), such as:
CYGWIN=no_nlink rsync c:/... z:/...
This allows the user to be free to decide where to relax POSIX compliance in
order to achieve speed.
It also allows application developers (such as 'git'), to decide in their code
how they want Cygwin to behave.
In 'git' for example, it does need stat's nlink (number of hard links), and
actually, not even n_ino (the inode number). Cygwin's git performance was
ultra-slow, and they improved it by not using Cygwin's stat(), rather
re-implementing their own 'quick-stat' which worked directly with Win32 API.
If Cygwin would have supported dynamic options (as opposed to mount time
options), instead of the large 'ifdef __CYGWIN__' code, it would simply be
adding 'setenv("CYGWIN", "no_nlink no_inode")' to the code in git's main().
Or, another way of looking at this is, instead of implementing their own
potentially buggy, imprecise stat() they could have not thought of
Cygwin as a black box and either 1) offered improvements for the DLL or
2) engaged the Cygwin community with requirements. If there is ifdef'ed
__CYGWIN__ code in git now that means that any performance improvements that
we (i.e., Corinna) has made will never be noticed and that code will be
maintained forever.
This allow applications to declare they will never look into the 'st_ino' and
'st_nlink'. The authors of an application, at the time of writing it, know
whether their code accesses these fields or not.
So, you're trading ifdef __CYGWIN__ in git with lots of if's in the very
parts of Cygwin code path where people complain about slowness.
But, anyway, if we were going to implement something like this, it wouldn't
be with environment variables, it would be with the proposed api that Eric
Blake has mentioned in the past.
cgf