Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3CF0C576.5B88E682@phekda.freeserve.co.uk>
Date: Sun, 26 May 2002 12:22:30 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
CC: pjfarley AT dorsai DOT org
Subject: Re: PATCH: fcntl and F_GETFL, mark 2
References: <10204061918 DOT AA13504 AT clio DOT rice DOT edu> <3CC72CFD DOT 5391DAFE AT phekda DOT freeserve DOT co DOT uk> <2561-Fri26Apr2002104641+0300-eliz AT is DOT elta DOT co DOT il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> > Date: Wed, 24 Apr 2002 23:09:01 +0100
> > From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
> >
> > I've just tested it under WinNT4+SP5 with SFN (no LFN TSR) under VMware
> > 3.1 and the results are weird. _get_sft_entry_ptr in
> > src/libc/posix/fcntl/fcntl.c returns some value, but then files are
> > reported as read-only irrespective of what mode they were opened with.
> > So it looks like the return value from _get_sft_entry_ptr is bogus. Or
> > maybe the SFT it points to is bogus.
> 
> There's some code in fstat that verifies the SFT pointer, perhaps you
> should use something similar in fcntl.
> 
> > The SFT handling code in fstat is pretty different. I wonder if that
> > works OK.
> 
> AFAIK, it does.

I've done a little more investigation. I don't think that Windows NT 4 SP5
emulates the SFT properly.

If I build src/libc/posix/sys/stat/fstat.c as a test program (using -DTEST)
and then run it on all files ("./fstat.exe *"), I get lots of messages like:

"chmod.c (7): 2 268435460 444 1 42 894 967152256 Thu Aug 24 21:24:16 2000
                        Times: 967152256 967152256
                        Block size: 4096
Failed to get starting cluster number; inode defaults to hashing
(if no other messages were printed, then this is either an empty
file on a local disk drive, or a file on a networked drive, or
you run under some kind of DOS clone)
SFT entry found, but is inconsistent with file size and time stamp"

Only handles 0, 3 and 4 seem to be found correctly. These are stdin, stdprn
and something else, I think.

I also compared the entry pointers returned by _get_sft_entry_ptr in
src/libc/posix/fcntl/fcntl.c and get_sft_entry in
src/libc/posix/sys/stat/fstat.c. They weren't quite the same, but they seem to
be in the same region of memory - 0x32d8 for fcntl.c's vs. 0x3290 for
fstat.c's.

Assuming that the SFT is actually found properly by either fcntl.c or fstat.c,
it seems that the flags are always set to read-only.

So I think we should ignore the result of _get_sft_entry_ptr in fcntl.c, when
trying to determine the flags to return for F_GETFL. I'll post a new patch
with some Windows NT 4 detection code, to make it always return O_RDWR for NT
4. Does this seem reasonable?

Thanks, bye, Rich =]

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