MFS: possible bad behaviour of the function exists

MFS: possible bad behaviour of the function exists

[Emmanuel Jeandel]

Hello,

I encountered the following problem (DOSEMU 1.1.3.4, i'm progressively
updating to 1.1.3.7, but i have not seen anything about this bug in patches
1.1.3.5 through 1.1.3.7)

With lredir, i associated D: with /home/foo, and E: with /home/foo/Games.
Let's say i have a file bar.exe in /home/foo/Games.

Now, in dosemu, if i say : 
PROMPT>D:
PROMPT>cd Games
PROMPT>bar
then bar is executed

However, if i execute :
PROMPT>E:
PROMPT>bar
bar.exe is not found (it is found by "dir", by "type", but i can neither
execute it nor modify it with an editor)

After some debugging, i found that the problem seems to be in mfs.c :
in the function exists, the ENTIRE path is lowercased, whereas the good
behaviour is to lowercase only the DOS part of the path (or rather to
not lowercase anything, cause find_file one line later will do this for us)

That's why i observed this behaviour : in the first case, find_file is
called with /home/foo/games/bar.exe, knowing that the unix part is /home/foo,
and then try any combination of lower and uppercase in games/bar.exe to find
that Games/bar.exe is the good one

In the second case, find_file is called with /home/foo/games/bar.exe,
knowing that the unix part is /home/foo/games (WRONG !), and then find
nothing, cause it will not do anything about the "games" part of the folder.


Then, this bug will cause the failure of any attempt to execute a file 
when the unix part of the path is not lowercase

My suggestion will be to comment/delete the line in exists speaking about
strlowerDOS.


Regards,
Emmanuel

Re: MFS: possible bad behaviour of the function exists

[J. Solomon Kostelnik]

On Sat, 2002-12-14 at 08:38, Emmanuel Jeandel wrote:
> However, if i execute :
> PROMPT>E:
> PROMPT>bar
> bar.exe is not found (it is found by "dir", by "type", but i can neither
> execute it nor modify it with an editor)

I get this same problem in 1.1.3.7 with all experimental patches
applied.  I have my C: linked to a real Linux directory,
/var/lib/dosemu/C -- if I try to edit (DOS' edit) anything in the root
directory it says "Edit was unable to access the file 'C:\'", even
though I typed "edit config.sys" in C:\ (it actually does the same thing
in any directory).  It also ends up deleting the file I was trying to
open.  However, ezedit works fine.

I also get some very strange behavior if I try to save a file.  If I
attempt to save to a filename that does not exist, it will ask me if I
want to replace the existing file!  If I say yes, it'll give me an error
that it wasn't able to write it, but I still end up with a new filename
named something like "ALCGDCEO."  Very odd.

Any ideas?

Solomon

Re: MFS: possible bad behaviour of the function exists

[Bart Oldeman]

On Sat, 14 Dec 2002, Emmanuel Jeandel wrote:

> My suggestion will be to comment/delete the line in exists speaking about
> strlowerDOS.

Thank you, that is indeed the correct solution, ie.,
--- mfs.c.old   Sat Dec 14 16:23:35 2002
+++ mfs.c       Sat Dec 14 16:24:20 2002
@@ -1008,7 +1008,6 @@
   while (fullname[len - 1] == '.')
     len--;
   fullname[len] = '\0';
-  strlowerDOS(fullname);
   rc = find_file(fullname, st);
   return rc;
 }

also thanks for finding out about a solution to the Bison problems.

Bart

Re: MFS: possible bad behaviour of the function exists

[Stas Sergeev]

Hello.

J. Solomon Kostelnik wrote:
> I get this same problem in 1.1.3.7
Well, your problem is probably not the
same.
If the patch submitted under the same
subject doesn't help you, read on.

> I also get some very strange behavior if I try to save a file.  If I
> attempt to save to a filename that does not exist, it will ask me if I
> want to replace the existing file!
I suffered from the same problem a lot.
It appears to be this:

--------D-216C00-----------------------------
INT 21 - DOS 4.0+ - EXTENDED OPEN/CREATE
	AX = 6C00h
	BL = open mode as in AL for normal open (see also AH=3Dh)
[]

BUG:	this function has bugs (at least in DOS 5.0 and 6.2) 
when used with
drives handled via the network redirector (INT 2F/AX=112Eh):
- CX (attribute) is not passed to the redirector if DL=11h,
- CX does not return the status, it is returned unchanged 
because
DOS does a PUSH CX/POP CX when calling the redirector.
---

In case you suffer this BUG (applies also to a
PC-DOS), then the only solution would be to
switch to FreeDOS.
This bug plagued all the DosNavigator users
to death when they tried it under dosemu.