Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3AF5D99A.5CA13EFD@phekda.freeserve.co.uk>
Date:	Mon, 07 May 2001 00:09:14 +0100
From:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer:	Mozilla 4.77 [en] (X11; U; Linux 2.2.17 i586)
X-Accept-Language:	de,fr
MIME-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC:	djgpp-workers AT delorie DOT com
Subject:	Re: ANNOUNCE: Fileutils 4.0 beta 2
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1010429092632 DOT 26520B-100000 AT is> <3AEC0365 DOT 6562B543 AT phekda DOT freeserve DOT co DOT uk> <9003-Sun29Apr2001205651+0300-eliz AT is DOT elta DOT co DOT il>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> > Date: Sun, 29 Apr 2001 13:04:53 +0100
> > From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
> >
> > Thanks for the bug report.
> 
> Here's another one ;-)
> 
> Put an empty floppy into drive A:, and then type this:
> 
>   C:\> ls a:
>   c:/djgpp/bin/ls: a:: No such file or directory (ENOENT)
> 
> This is on Windows 98.  On plain DOS 5.0, it gets more interesting:
> 
>   C:\> ls a:
>   c:/djgpp/bin/ls: a:: No more files (ENMFILE)
> 
> `ls' from Fileutils 3.16 would simply print nothing in this case,
> which is what I'd expect.

Are you using 2.03-compiled Fileutils 3.16? I get a similar behaviour from
'ls' from the latest release of Fileutils 3.16 on the DJGPP archive:

bash-2.04$ /temp/bin/ls.exe --version
ls (GNU fileutils) 3.16
bash-2.04$ /temp/bin/ls.exe a:
/temp/bin/ls: a:: No such file or directory (ENOENT)

I don't have a DOS 5 box anywhere. I wonder if the 2.03-compiled version
would generate the ENMFILE error too?

> Curiously enough, I cannot get the same results with hard disks, only
> with a floppy.

This only seems to happen with empty disks - I had to remove all files on
the disk, before I got the same error. As to it (not) working on a hard
disk - I imagine that you would need an empty hard disk for this to work.
I don't have an empty hard disk. I tried mapping a share with no files to
a drive letter, to simulate an empty disk. ls worked OK with that drive
letter - presumably because Samba provides '.' and '..' entries.

Now to the cause of the error: closedir() calls rewinddir(). rewinddir()
fails with ENOENT (or ENMFILE?). closedir() then fails, passing through
the error.

Debugging libc I see that rewinddir() calls __set_need_fake_dot_dotdot().
__set_need_fake_dot_dotdot() calls findfirst(). On a floppy with no files
findfirst() fails, returing ENOENT. Hence __set_need_fake_dot_dotdot()
sets errno. It seems to me that it should not set errno. I think code
should be added to it, to save and restore errno. Is this a libc bug?

Thanks, bye, Rich =]

-- 
Richard Dawe
http://www.phekda.freeserve.co.uk/richdawe/

- Raw text -