Re: Freedos bugs and Freedos with Linux bugs

27 views
Skip to first unread message

Rod Pemberton

unread,
Nov 5, 2018, 6:28:58 PM11/5/18
to
On Mon, 5 Nov 2018 14:17:57 -0800 (PST)
sdn4...@gmail.com wrote:

> I have found some bugs with FREEDOS/DOSEMU/LINUX and Freedos by
> itself.

You could've posted this to alt.os.free-dos. Added. From c.o.m.p.

> When I try to create a file using normal DOS system calls
> using freedos and there is no 'stderr.txt' in the directory I am
> using, then my program doesn't work. It works fine with MSDOS 3.3,
> DRDOS 6, and Win XP DOS 100%.

...

> I found that creating the 'stderr.txt' file first using ECHO
> >stderr.txt seems to solve the problem with freedos.

...

> When copying files from a Linux filesystem to a DOS 32 filesystem, the
> filenames are changed from lowercase on the Linux filesystem to
> uppercase on the DOS 32 filesystem.

That's correct. DOS is uppercased 8.3 filenames, 8 characters of the
name and 3 for the extension. 32-bit VFAT disk routines with FAT 32
filesystem via Windows 95/98/SE/ME also added mixed-case support via
LFNs (long-file names). So, a DOS FAT 32 filesystem will have both
SFNs (short-file names) in 8.3 and long-filenames stored in a special
directory format. The long-filenames are only visible or accessible in
Windows 95/98/SE/ME etc, unless you install a special TSR in DOS with
LFN filename support, such as DOSLFN. DOSLFN installs the LFN API
except for two less common LFN calls, IIRC, which are natively available
in MS-DOS v7.00 to v8.00.

DOSLFN
http://adoxa.altervista.org/doslfn/

> I formatted the DOS filesystem as
> Fat 16 but when I checked the result it turned out to be Fat 32
> (using Linux).

It may be too large of a partition to be FAT 16, or Linux tools may not
support larger FAT 16 sizes, i.e., defaulting to FAT 32 at a
reasonable size. E.g., FAT 16 is usually limited to 2GB and FAT32 is
usually limited to 127GB, either by the OS (operating system) or by the
OS' formatting tools, even though FAT 32 has a theoretical 2TB maximum
partition size, etc. E.g., Windows NT can't read "over-sized" FAT
partitions that can be created with Windows 98/SE/ME tools. So, in
addition to a standard maximum partition size, and a theoretical
maximum partition size, each OS and it's tools have their own limits.

> Linux should convert filenames to all lowercase when it copies to a
> DOS filesystem.

No, it shouldn't. DOS doesn't support lowercase natively. Mixed case
is only available with VFAT and FAT 32 i.e., Windows 95/98/SE/ME etc, or
when you load an LFN driver in DOS. I.e., there is no reason for Linux
to ever produce lowercase for FAT 16, but should copy LFNs for FAT 32 as
well as 8.3 SFNs. You can only see LFNs with an LFN driver or under
Windows 95/98/SE/ME etc.

> FREEDOS should also convert all filenames to
> lowercase before storing the name to anywhere.

Again, no.

> If you look in Linux /usr/bin you will probably see all (or nearly
> all) lowercase filenames for executables.

Yes, Linux natively supports mixed case and long filenames as part of
it's filesystem(s). DOS didn't, originally. This came with Windows
95/98/ME/SE extensions to MS-DOS (v 7.00, 7.10, 8.00). I.e., this LFN
extension is /NOT/ a part of Free-DOS, DR-DOS, IBM DOS, nor earlier
versions of MS-DOS such as 6.22 or 5.00 etc, but LFNs may work with
these other DOS' by using a DOS LFN driver.

> This makes for a problem with renaming files between across
> filesystem copies to restore valid filenames.

You should use a file archiver that preserves long filenames, e.g.,
tar+gzip for Linux which also has LFN-aware DOS port, e.g., from DJGPP
project, then load a DOS LFN driver in DOS and untar/ungzip, or use
Windows 98/SE/ME etc with LFN-aware untar/ungzip to extract and preserve
said LFNs. Again, you'll need an archiver that's available for both
Linux and DOS or Windows, and has LFN support on the DOS/Win side. I
would suspect that Info-ZIP for Linux and a late version of PKZIP for
DOS with a loaded LFN driver might work too. I'm not sure if BZIP is
available for DOS.

http://www.delorie.com/djgpp/


From an old post of mine, circa 2010 to c.l.a.x, I mentioned some LFN
aware tools:

"PKZIP/PKUNZIP v2.50 and DJGPP's Unzip32.exe are LFN-aware. Henrik
Haftmann's DOSLFN is the best LFN driver. Jason Hood has updated the
driver. Odi's LFN Tools by Ortwin Glueck may help too, e.g., lren,
ldir, etc. DJGPP also has other DOS LFN aware tools such as: gzip,
cpio, and DJtar. Gero Kuhlmann's rpmunpac has been posted by me with
DOS LFN updates for OpenWatcom and DJGPP in comp.os.msdos.djgpp and
openwatcom.contributors."

Odi's LFN Tools
http://lfntools.sourceforge.net/

> I have even had files
> copied between filesystems where Linux refused to rename a file from
> uppercase on the Linux filesystem to a lowercase filename on the same
> Linux filesystem. These are bugs in my opinion with Linux and Freedos.

...?

Yeah, I'm not sure what that's about, unless it was on the same DOS
partition but just installed into a Linux filesystem. So, no change of
the actual filesystem? Or, perhaps you didn't have sufficient account
privilege (see root, sudo) or directory privilege to move or rename on
the Linux side, i.e., no write access to the directory (see chmod,
chown).

> I would take this to a Linux group if I could find one that had any
> traffic this year. :-/

Go ahead and post to one anyway. Usually, there are plenty of
"lurkers" (read only) who may hit you up via Google Groups to Usenet,
and there are frequently non-responding Usenet "regulars", because there
is no traffic, i.e., they're waiting. If they're on Usenet, they'll see
new marked posts in their newreader. Google Groups usually moves the
old thread to the top if some is posting.

>
> Steve www.ml1compiler.org

HTH,


Rod Pemberton
--
"The most ironic outcome is the most probable." Elon Musk
Could someone tell Elon that means Tesla implodes? ...

sdn4...@gmail.com

unread,
Nov 6, 2018, 5:17:05 PM11/6/18
to
On Monday, November 5, 2018 at 3:28:58 PM UTC-8, Rod Pemberton wrote:
> On Mon, 5 Nov 2018 14:17:57 -0800 (PST)
> sdn4...@gmail.com wrote:

> You could've posted this to alt.os.free-dos. Added. From c.o.m.p.

Found it Rod,
Well as I pointed out (comp.os.msdos.programmer) which is MSDOS I admit
but is general DOS programming also: The problem is mostly Linux/DOSemu/Freedos
and using Linux to copy a DOS 8.3 lowercase filename (because on screen it's
lowercase as well as when typed in) and Linux changing lowercase from Linux to
uppercase on the real DOS drive. No big deal except that a copy from there back
to Linux makes it uppercase and no longer usable in some situations without
a rename back to lowercase which Linux often refuses (can't copy a file onto
itself). The bottom line is that lowercase 8.3 should be lowercase 8.3 no
matter what file system it's on.

Also sometimes things don't work right in Freedos when the 'stderr.txt' file is
missing. Weird. ECHO >stderr.txt seems to fix it for me.

Steve www.ml1compiler.org

Grant Taylor

unread,
Nov 6, 2018, 7:07:21 PM11/6/18
to
On 11/06/2018 03:17 PM, sdn4...@gmail.com wrote:
> The problem is ... using Linux to copy a DOS 8.3 lowercase filename
> ... and Linux changing lowercase from Linux to uppercase on the real DOS
> drive. No big deal except that a copy from there back to Linux makes it
> uppercase and no longer usable in some situations without a rename back
> to lowercase....

I would expect this behavior.

FAT by itself (without VFAT) has no concept of case. As such,
everything is in upper case.

When Linux copies a file to FAT it has to fold the case. This folding
process looses the fact that the original file was in lower case. There
is simply no way for FAT to store that something was lower case.

Thus when you copy a file from FAT to a file system that supports mixed
case, cp (or any other operation) can only use the data that is
available. Seeing as how there is zero case information, everything
defaults to upper case.

The copy to FAT and the copy from FAT are completely disparate
operations and have no information transfer between the separate processes.

So what you are claiming is a bug is actually intended behavior. It may
very well be undesired behavior. But it is none the less working as
intended.

> ...Linux often refuses (can't copy a file onto itself).

Linux file systems that are case sensitive should be able to move from
the uppercase name to the lowercase name without any problem because
they are two separate file names to Linux.

> The bottom line is that lowercase 8.3 should be lowercase 8.3 no matter
> what file system it's on.

The first copy (to FAT) is forced to fold to uppercase. There is no
choice in the matter.

The second copy (from FAT) is preserving the source case, namely uppercase.

In my opinion, this behavior is working as intended and as I would expect.



--
Grant. . . .
unix || die

sdn4...@gmail.com

unread,
Nov 7, 2018, 2:17:30 PM11/7/18
to
On Monday, November 5, 2018 at 3:28:58 PM UTC-8, Rod Pemberton wrote:
> On Mon, 5 Nov 2018 14:17:57 -0800 (PST)
> sdn4...@gmail.com wrote:
Hi Grant,
My recollection of DOS3.3 (the common denominator IMO) is that everything is displayed as
lowercase with DIR, etc.
I unzipped some DOS stuff yesterday on Windows XP DOS and all lowercase filenames
and dirnames were indeed made uppercase and displayed a such. But when I thereafter created a
file using WINDOS system calls they were lowercase (because of the lowercase name)
and displayed as such. All of it works fine.
But I have directory names on freedos in fake FAT16 (which Gparted created)
which is really part Fat32 (something in between as it looks), so some
directory names are lowercase and some uppercase and displayed as such, even though all were
created as lowercase, which indicates that the filename can be stored as
lowercase or uppercase filenames and directory names.

When you copy a lowercase file from Linux then the DOS directory should
then understand that it's lowercase because FAT will display newly created
lowercase filenames as lowercase,
but instead the lowercase name becomes uppercase.
Intended behavior or not, I still consider this a bug. :-/
Mixed uppercase and lowercase when all were typed in as lowercase.

Steve

////
>>--O O-->
- "Pardon the line format, CRs are invisible on this editor"
Reply all
Reply to author
Forward
0 new messages