Date: Wed, 30 Oct 96 17:18:06 GMT
Message-Id: <9610301718.AA27269@leopard.proteon.com>
From: Neil Jarvis <Neil DOT Jarvis AT proteon DOT com>
To: eliz AT is DOT elta DOT co DOT il
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.961023075804.6813C-100000@is> (message from Eli
	Zaretskii on Wed, 23 Oct 1996 08:00:02 +0200 (IST))
Subject: Re: ar on networked drive
Reply-To: Neil DOT Jarvis AT proteon DOT com
Mime-Version: 1.0 (generated by tm-edit 7.43)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Eli" == Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> writes:

    Eli> On Tue, 22 Oct 1996, Neil Jarvis wrote:

    >> Hope this can be fixed soon, as I am trying to rebuild a debug version
    >> of 'ar.exe' to investigate why it does not work on a networked drive.....
    Eli> What, again?  Last time it was `ld', but that should have
    Eli> been solved...  Is this `ar' from Binutils 2.7 ported for
    Eli> v2.01?  If so, how exactly does it fail and what network
    Eli> software do you use?

OK, here's what I found out. I'm using ar from Binutils 2.7. It passes/fails
in the following fashion:

test.c:
-------

int main()
{ 
   printf("Oh no, not again\n");
}

ar working on DOS 6.22, C drive  PASSES.
-------------------------------

C:\> gcc -c test.c
C:\> rm libtest.a
C:\> ar rv libtest.a test.o
a - ret_code.o

ar failing on DOS 6.22, I drive (NFS mounted Sun disk) FAILS.
------------------------------------------------------

I:\> gcc -c test.c
I:\> rm libtest.a
I:\> ar rv libtest.a test.o
z:/djgpp.201/bin/ar.exe: libtest.a: No such file or directory (ENOENT)

Analysis
--------

In src/libc/posix/sys/stat/stat.c, the function

        stat_assist(const char *path, struct stat *statbuf) 

exhibits different characteristics depending on whether the
destination disk drive for the library file is local or networked.

In the case that works, with a local disk drive, the function reaches
the following piece of code 

       /* Check for volume labels.  We did not mix FA_LABEL with
	 other attributes in the call to `__findfirst' above,
	 because some environments will return bogus info in
	 that case.  For instance, Win95 and WinNT seem to
	 ignore `path' and return the volume label even if it
	 doesn't fit the name in `path'.  This fools us to
	 think that a non-existent file exists and is a volume
	 label.  Hence we test the returned name to be PATH.  */
      if (!__findfirst(path, &ff_blk, FA_LABEL))

which fails to return a volume label on my PC. This causes the 'else'
clause to be executed, converting the errono from ENMFILE to ENOENT
and exiting the function:

	  /* FindFirst might set errno to ENMFILE; correct that.  */
	  if (errno == ENMFILE)
	    errno = ENOENT;
	  return -1;

This is OK, and ar.exe creates a new file and works.

In the case of the networked drive the same call to 

      if (!__findfirst(path, &ff_blk, FA_LABEL))

returns a volume label, but the code inside the 'if' statement doesn't
like the result and executes a 'break', missing the conversion of the
errno from ENMFILE to ENOENT and return from the function. This causes
the stat_assist() call to continue executing, eventually returning
with errno not set to ENOENT. (Which it must be for ar.exe to work).

I think the conversion test should be moved outside the first group of
if/elses to catch all the cases of failure, where errno = ENMFILE. But
I don't understand this routine, or why it is even looking at volume
labels, so I am looking to the experts for a fix.

Hope I have diagnosed enough of the problem to point you in the right
direction.

Cheers,

-- Neil Jarvis, Proteon International R&D, York, UK. (Neil DOT Jarvis AT proteon DOT com)