Subject: Re: bug#15933: make check not working

From: Eli Zaretskii <[email-masked]>
Date: Mon, 25 Nov 2013 19:15:11 +0200

> From: Michael Albinus <[email-masked]>
> Date: Mon, 25 Nov 2013 13:31:03 +0100
> Cc: [email-masked]
> 
> Andy Moreton <[email-masked]> writes:
> 
> > The log from my most recent run of 'make check' ended with:
> >
> > --[make check]----------------------------------------------
> > Indenting module modname...done
> >    passed  180/521  f90-test-bug8691
> >    passed  181/521  f90-test-bug8820
> >    passed  182/521  f90-test-bug9553a
> >    passed  183/521  f90-test-bug9553b
> >    passed  184/521  f90-test-bug9690
> >    passed  185/521  f90-test-indent
> >    passed  186/521  file-notify-test00-availability
> >   skipped  187/521  file-notify-test00-availability-remote
> >    passed  188/521  file-notify-test01-add-watch
> >   skipped  189/521  file-notify-test01-add-watch-remote
> > make[1]: *** [check] Error 5
> > make[1]: Leaving directory `/c/emacs/src/emacs/trunk/obj-mingw32/test/automated'
> > --[make check]----------------------------------------------
> 
> Thanks. However, I haven't seen this information somewhere else yet. I
> believe, it is worth another bug report.
> 
> > I haven't got any further looking into this as the machine I was using
> > died last week...
> 
> Oops. Please indicate in the bug report the environment you were
> using. I guess it was MS Windows whatever (which might it make hard for
> me to debug, 'cause I don't use it).

It might be easy enough to guess why it fails.  I see this in
file-notify-tests.el:

  ;; There is no default value on w32 systems, which could work out of the box.
  (defconst file-notify-test-remote-temporary-file-directory
    (if (eq system-type 'windows-nt) null-device "/ssh::/tmp")
    "Temporary directory for Tramp tests.")

How is this supposed to work?  null-device is not a directory.  I'm
guessing that "Error 5" is "access denied" emitted by Windows because
some file primitive tries to treat null-device as if it were a
directory.

If you could explain what you intended to achieve by that, perhaps I
could suggest a solution.  (Does "/ssh::/tmp" assume there's an sshd
running on the machine that runs the tests?)