Re: Problem with v133

> [joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) writes:]
>
> >Now I did an ls, works. cd'd to vsta, ls, works. But whenever I cd
> >into a second subdir and do an ls there the dos server dies.
>
> You need to gather a stack backtrace of the DOS server, along with the
> output of "tf". Obviously, I was able to cd down multiple levels of
> directories, so it's not a generic problem.

I have the same problem, in fact, I can't "ls" in / either.
I actually have a few variables going on in my system which may spice
it up a bit, I figure one of them is responsible for whatever the
VSTa dos server dosn't like. However, everything else thinks the
FAT is fine so it probably is actually a VSTa dos server problem.
(VSTa dos surely is tempermental)

1) I have OS/2 on my machine and it stores weird "wp root.sf" files for
   Extended Attributes on FAT. (actually one file in the root directory)
2) I have Win95 on my machine and it has long filename extensions (it's
   some backward compatible thins.. OS/2 has no problem with it)
3) I untarred vsta from Linux directly onto the msdos partition.

Having all these variables probably dosn't help, but then again, it
brings out the best bugs :) I used to only have problems doing
"ls" in the root directory so I just stayed below "vsta". Since I
installed 1.3.3 I can't "ls" in several of the places below /vsta.
(when I say "ls" replace that with "do anything usefull in the directory")

Anyhow, As soon as I can clean up the FAT enough so VSTa will let me
compile (or even get into srv/dos for that matter) I'll try and see
what I can do.

Here is a "bt" from right after it died:

trace(0x0,0xc0de88,0x1ffc1c0,0x1ffc100) called from do_cmd+a5
do_cmd(0xc0de88) called from dbb_main+92
dbg_main(0x2d6b) called from dbg_enter+15
dbg_enter(0xae69,0x8) called from do_exit+104
do_exit(0x10000,0x1ffe734,0xc0df98) called from sendev+62
sendev(0x1ffc100,0xc0df98) called from check_events+104
check_events(0x5b5a,0x7fffff20,0x7ffffe8c,0x12c8) called from trap_2eb
trap(0x2b002b,0x7fffff30,0x7fffff20,0x7ffffe8c) called from trap_common+10

and output of "tf"

Trap type 255 err 0x0 eip 0x33:0x599a
                      eax 0x00
                      ebx 0x5b5a
                      ecx 0x5
                      edx 0x400000
                      esi 0x7fffff20
                      edi 0x7fffff30
                      esp 0x2b:0x7ffffe70
                      ebp 0x7ffffe8c
                      eflags 0x246

I don't know how helpfull that is, since it's not a "dos" backtrace.
At the risk of saying something stupid, why does it trap? Is that an
"intentional" trap because the filesystem disappeared?

-- 
jeske_at_uiuc.edu    + David Jeske(N9LCA)<A HREF="http://www.cen.uiuc.edu/~jeske/">
NeXTMail accepted + CompEng Student/NeXT Programmer/Call Gtalk at (708)998-0008
    User of Linux/NEXT/DOS/WIN/OS.2/VSTa (all coexisting on one system) </A>