Test failure for v2.16.0-rc0 on cygwin

Hi Junio, Adam,

Just a quick note about the failure of the test-suite on cygwin. In particular, test t5580-clone-push-unc.sh #3, like so:

  $ ./t5580-clone-push-unc.sh -i -v

  ...

  ok 2 - clone
  
  expecting success: 
  	(
  		cd clone &&
  		git checkout -b to-push &&
  		test_commit to-push &&
  		git push origin HEAD
  	) &&
  	rev="$(git -C clone rev-parse --verify refs/heads/to-push)" &&
  	test "$rev" = "$(git rev-parse --verify refs/heads/to-push)"
  
  Switched to a new branch 'to-push'
  [to-push 0adccbe] to-push
   Author: A U Thor <author@example.com>
   1 file changed, 1 insertion(+)
   create mode 100644 to-push.t
  Counting objects: 3, done.
  Delta compression using up to 4 threads.
  Compressing objects: 100% (2/2), done.
  Writing objects: 100% (3/3), 289 bytes | 289.00 KiB/s, done.
  Total 3 (delta 0), reused 0 (delta 0)
  error: remote unpack failed: unable to create temporary object directory
  To file:////localhost/C$/\cygwin64\home\ramsay\git\t\trash directory.t5580-clone-push-unc
   ! [remote rejected] HEAD -> to-push (unpacker error)
  error: failed to push some refs to 'file:////localhost/C$/\cygwin64\home\ramsay\git\t\trash directory.t5580-clone-push-unc'
  not ok 3 - push
  #	
  #		(
  #			cd clone &&
  #			git checkout -b to-push &&
  #			test_commit to-push &&
  #			git push origin HEAD
  #		) &&
  #		rev="$(git -C clone rev-parse --verify refs/heads/to-push)" &&
  #		test "$rev" = "$(git rev-parse --verify refs/heads/to-push)"
  #	
  $ 

My first, knee-jerk, reaction on seeing the backslashes in the 'local' part of the pathname (despite what it says in commit f21d60b429) was to replace the 'cygpath -aw .' with 'cygpath -am .'. This leads to exactly the same error display as above, except '\\' replaced by '/' in the pathname! Hmm.

Note:

  $ ls '//localhost/C$/\cygwin64\home\ramsay\git\t\trash directory.t5580-clone-push-unc'
  clone/  initial.t
  $ ls '//localhost/C$//cygwin64/home/ramsay/git/t/trash directory.t5580-clone-push-unc'
  clone/  initial.t
  $ ls //localhost/C$/\\cygwin64\\home\\ramsay\\git\\t\\trash\ directory.t5580-clone-push-unc
  clone/  initial.t
  $ 
 
So, after some debugging (using the 'cygpath -am .' version), it seems that
the error message is caused by the mkdtemp() call in tmp_objdir_create()
function (tmp-objdir.c:123), failing with an errno of 'permission denied'. 

At the time of the call to mkdtemp, the current working directory is given by '//localhost/C$/cygwin64/home/ramsay/git/t/trash directory.t5580-clone-push-unc/.git', and the parameter to mkdtemp is (for example) "./objects/incoming-MgZCkI".

  $ cd trash\ directory.t5580-clone-push-unc/
  $ ls
  clone/  initial.t
  $ ls .git
  branches/       config       HEAD             index  logs/     refs/
  COMMIT_EDITMSG  description  hooks-disabled/  info/  objects/
  $ ls .git/objects
  24/  93/  e7/  info/  pack/
  $ mkdir '//localhost/C$//cygwin64/home/ramsay/git/t/trash directory.t5580-clone-push-unc/.git/./objects/incoming-MgZCkI'
  mkdir: cannot create directory ‘//localhost/C$//cygwin64/home/ramsay/git/t/trash directory.t5580-clone-push-unc/.git/./objects/incoming-MgZCkI’: Permission denied
    $ 

So, when 'doing it by hand', I get the same result. ;-)

Looking at the permissions:

  $ ls -ld '//localhost/C$//cygwin64/home/ramsay/git/t/trash directory.t5580-clone-push-unc/.git/./objects'
  drwxr-xr-x+ 1 ramsay None 0 Dec 30 13:51 '//localhost/C$//cygwin64/home/ramsay/git/t/trash directory.t5580-clone-push-unc/.git/./objects'/

  $ ls -ld '//localhost/C$//cygwin64/home/ramsay/git/t/trash directory.t5580-clone-push-unc/.git'
  drwxr-xr-x+ 1 ramsay None 0 Dec 30 13:51 '//localhost/C$//cygwin64/home/ramsay/git/t/trash directory.t5580-clone-push-unc/.git'/

  $ ls -ld '//localhost/C$//cygwin64/home/ramsay/git/t/trash directory.t5580-clone-push-unc'
  drwxr-xr-x+ 1 ramsay None 0 Dec 30 13:51 '//localhost/C$//cygwin64/home/ramsay/git/t/trash directory.t5580-clone-push-unc'/

  ... and so on, until:

  $ ls -ld '//localhost/C$'
  d---r-x---+ 1 TrustedInstaller TrustedInstaller 0 Oct 28 16:16 '//localhost/C$'/
  $ 

Doing a quick web-search on '//localhost/C$' lead me to several posts which seem to suggest the problem could be related to UAC filtering on remote shares (and the fact that I am on Windows 10), along with a registry setting for 'LocalAccountTokenFilterPolicy'. However, I have not had time to look into any of that.

Adam, are you running the tests on Windows 10?

I have to go now, so I can't look at this further today. Just FYI.

ATB, Ramsay Jones