Environment to run tests in, changing file permissions on Cygwin

[Dr Rainer Woitok]

Matt,

On Friday, 2016-01-29 13:04:43 -0600, you wrote:

> ...
> Exec bits are not a concept native to Windows.

Hm, native Windows knows about  "R" (read) permission, which is equival-
ent to Unix "r--",  and it knows about  "RX" (read  or execute, traverse
folder) permission, which is equivalent to Unix "r-x", even for folders.
So when Windows  native ACLs  deny "R"  and grant "RX",  this is exactly
equivalent to Unix "--x".  And it is native.

I agree that Windows doesn't at all care  about the exec bit and normal-
ly gives "F" (full) permission to any file a user creates.   But is this
relevant for Mercurial?   After all,  its purpose is  to record changes,
and if a user changes Windows ACLs for some file,  why shouldn't Mercur-
ial record this, too, even if the changes are in the exec bit?

> ...
> In particular, if os.name == 'nt', then we import windows.py, which defines
> checkexec() to return False.

I think short-circuitting these tests  is a bad decision,  see below for
my reasoning.

> So, what does this say for you:
> 
> $ python -c "import os; print os.name"

$ python -c "import os; print os.name"
posix
$

> (Make sure you test both the Python hg i thats configured to use and whatever
> one you use to run run-tests.py)

Well, as far as I can see  there's only one Python installed on my syst-
em:

$ ls -l /usr/bin/python*
lrwxrwxrwx 1 Chef win   13 2015-07-15 17:02 /usr/bin/python -> python2.7.exe
lrwxrwxrwx 1 Chef win   16 2015-07-15 17:02 /usr/bin/python-config -> python2.7-config
lrwxrwxrwx 1 Chef win   13 2015-07-15 17:02 /usr/bin/python2 -> python2.7.exe
lrwxrwxrwx 1 Chef win   16 2015-07-15 17:02 /usr/bin/python2-config -> python2.7-config
-rwxr-xr-x 1 Chef win 1685 2015-06-02 01:20 /usr/bin/python2.7-config
-rwxr-xr-x 1 Chef win 8733 2015-06-02 01:20 /usr/bin/python2.7.exe
$

And Cygwin's  stock Mercurial  package  resides in  "/usr/lib/python2.7/
site-packages/", too.

> If it says "posix", exec bit support is checked with this code:
> 
> https://www.selenic.com/hg/file/tip/mercurial/posix.py#l150
> 
> Basically:
> 
> - create a temp file
> - flip the exec bit
> - check if the exec bit changed

That's exactly  what the small  shell script listed  in my previous mail
did.   Successfully,  mind you.   So why doesn't  Mercurial notice that?
The answer is in "posix.py" starting at line 290 or so:

if sys.platform == 'cygwin':
    . . .
    # Cygwin translates native ACLs to POSIX permissions,
    # but these translations are not supported by native
    # tools, so the exec bit tends to be set erroneously.
    # Therefore, disable executable bit access on Cygwin.
    def checkexec(path):
        return False

    # Similarly, Cygwin's symlink emulation is likely to create
    # problems when Mercurial is used from both Cygwin and native
    # Windows, with other native tools, or on shared volumes
    def checklink(path):
        return False

So basically what happens here  is Mercurial saying  "No, you're Cygwin,
you just cannot be Posix compliant,  no need for  testing it at all".  I
would suggest  to have  Mercurial do  as sophisticated  Posix compliance
tests as it deems necessary,  but then to accept the particular outcome,
rather than just short-circuitting  the test based on ... well, assumpt-
ions about  a mixed use  of Tortoise  and Cygwin's  Mercurial  (how many
people do that?).

It's been three years now  that I use a  patch against  "posix.py" which
comments out exactly  these last two lines above,  because I desparately
need symlink  support in my Mercurial repositories.   Up to now I cannot
report any ill side effects.   I'll probably just comment out the short-
circuitted "checkexec" definition, too, and see what happens.

So your memory was right: in Mercurial releases prior to 2.2 a change of
the exec bit was noticed under Cygwin.

> ...
> It's unclear whether Mercurial supporting exec bits under any circumstances on
> Windows is "a good thing". It will almost certainly lead to confusing, awful bug
> reports as people try to use THG and Cygwin hg against repos on the same disk.

I agree that this might cause problems,  but then the solution should be
to prevent Mercurial running under Cygwin from executing "pull" or "com-
mit" commands  against repositories  last modified  by Tortoise and vice
versa.  But just dropping  exec bit or  symlink support for Cygwin, even
though it is Posix compliant, surely doesn't seem the right thing to do.

Sincerely,
  Rainer