Mail Archives: djgpp-workers/2005/04/10/07:56:37
According to Charles Sandmann:
> > 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.
It does work with regard to writing. It's detecting that we can't
write anything more that is not working. After reaching the limit
size, I don't hear any more clicks from the hard drive but the light
diode that indicates hard disk activity continues to shine/flicker. So
it continues to try to do something on the hard drive even though
there's no point.
Anyway, after hitting C-c I do have a 4,294,950,912 bytes big file
with contents that match what I wrote ("012345678\n" repeated
eternally). Note that the size I get it 4GB-2^14 which seems a little
low, but as I C-c-ed the programm we can't be sure where the missing
2^14-2 bytes went. (My belief is that FAT32 should be able to support
file sizes <= 4GB-2.)
And me playing around with FreeDOS some years ago, makes me think that
the problem here is either a bug in FreeDOS or that it returns an
error code that DJGPP doesn't expect (which also probably is a bug in
FreeDOS).
> > 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.
Ok. Sorry. Now I've successfully opened a file from DOS COMMAND.COM
window in WINDOWS 98 on my Linux Samba share. Without (environment
variable) LFN set, LFN set to y and LFN set to n.
I won't bother with DOS 6.22.
Now, I've also tested that I could open and read my almost 4GB file in
FreeDOS as well.
> 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.
Indeed. If the bug is in the server, it looks to me that it will be
expensive or impossible finding out whether to pass the FAT32 extended
size flag or not.
The easiest would be just to try opening again without the flag if it
fails with the flag.
Right,
MartinS
Here are my test programs. In case there's something I missed. (They
are not wonders of efficiency or user friendliness.)
Creator:
#include <errno.h>
#include <stdio.h>
int main(void)
{
FILE *f;
int ret;
unsigned long long count;
f = fopen("x", "wb");
if( !f )
{
printf("Failed to open x (errno=%d).\n", errno);
return 1;
}
ret = fprintf(f, "0123455678\n");
count = ret;
while( 0 < ret )
{
ret = fprintf(f, "0123455678\n");
count += ret;
}
fclose(f);
printf("Wrote %lld (0x%08llx) bytes.\n", count, count);
return 0;
}
Reader:
#include <errno.h>
#include <stdio.h>
int main(void)
{
char ch;
FILE *f;
int ret;
unsigned long long count;
f = fopen("x", "rb");
if( !f )
{
printf("Failed to open x (errno=%d).\n", errno);
return 1;
}
ret = fscanf(f, "%c", &ch);
count = ret;
while( 0 < ret )
{
ret = fscanf(f, "%c", &ch);
count += ret;
}
fclose(f);
printf("Read %lld (0x%08llx) bytes.\n", count, count);
return 0;
}
- Raw text -