Mail Archives: djgpp-workers/2005/04/09/16:12:34
> According to Charles Sandmann:
> > If someone can find a short name only environment that needs files over
> > 2GB, and can show they work, I would suggest they re-write the code to
> > support it, without breaking DOS networking.
>
> Yes, FreeDOS does support 4GB (less two bytes or thereabout) files on
> FAT32. (However there are a bug somewhere as the program never stopped
> trying to write to the file. I had to C-c it. However I have no time
> to dig into this.)
This is disturbing - maybe it doesn't work.
> Furthermore I have no problems creating files on a Linux Samba share
> from either MSDOS 6.22 with MS TCP/IP or DOS COMMAND.COM window in
> WINDOWS 98.
Creating files was never a problem for the OP, only opening existing
files.
DOS 6.x shouldn't matter, since it would not try to set the extended
size flag. W98 did seem to cause a problem with the OP opening
existing files.
> However this shows that Charles's (or his bug
> reporter's) bug is WINDOWS (I don't remember which version(s) he
> mentioned) file server specific. In that case it was impossible to
> open the file (right?).
The reporter says in report #1:
> I am using FreeDOS kernel version 1.1.35 (Build 2035) [May 30 2004],
> Kernel compatibility 7.10 - WATCOMC - FAT32 support. I am using the
> Microsoft DOS TCP/IP network client mapping a drive to a Windows 2000
> Professional computer.
In a second report, he has migrated to Windows 98 DOS (no comment on
first or second edition), presumably same Microsoft Networking (no
comment on exact version), and notes:
> A call to _open(filename, O_RDONLY) returns -1. errno is 10, and
> _doserrno is 80.
Note: this error is file exists, which we would hope so ...
So it may be a problem with the Windows 2000 as the server, if it is
sent this FAT extended flag. It is documented in the comments that
Windows 2000 fails open calls with this flag; maybe it fails also
if sent this flag as the server. It could also be your test above
was a file create instead of an open of an existing file. More
testing is required.
A quick analysis of _open does not show a good way to fail and
retry without a complete restructuring of the code, or maybe additional
flag variables. Since _open can be sent anything from files without
paths to devices with prepended drives - trying to determine if it's a
network file is not trivial either.
There is always the chance that the LFN big bit set call fails with
Windows 2000 as the server also.
I haven't committed the change while we discuss. I also do not
have time this week to do testing, since it's the annual insanity
known as income tax time.
- Raw text -