From: BlameTroi
Eric,
>> C:\ELVIS\DOC>find /i "env" e*.htm
>> file list ...
>> Error reading from drive A: DOS area: general failure
>
> Does the same bug happen with find /i "env" C:e*.htm
> and with find /i "env" C:\elvis\doc\e*.htm by the way?
Yes it does. I've
From: Eric Auer
Hi Troi,
> C:\ELVIS\DOC>find /i "env" e*.htm
> file list ...
> Error reading from drive A: DOS area: general failure
You mean it FIRST checks all files in the current
directory on C: but THEN tries to jump to the A:
drive? That sounds like a bug in the
From: BlameTroi
I'm curious as to why FreeDOS is trying to read a:. I've built a VM in
VirtualBox and most things work well, but while digging around looking
for information, I got this after a FIND command.
C:\ELVIS\DOC>find /i "env" e*.htm
. file list ...
Error
From: Tom Ehlert
I could reproduce this.
it happens in/after findnext()
this error is related to the compiler.
if the source is compiled using TurboC 2.01 the error occures.
compiling the exact same source with TCPP the error is gone.
try
From: BlameTroi
Eric,
In the three cases (mine and your two suggestions) if DOSLFN is loaded
and enabled, there is no sign of a problem.
If DOSLFN is not loaded, I get the error.
If DOSLFN has been loaded, but I disable it (DOSLFN /D), the error returns.
So, DOSLFN seems
From: Eric Auer
Hi Rugxulo and Troi,
>> It could be a rare kernel bug, but my guess is some buffer overflow in the
>> IO95 lib. I think this problem is hidden by enabling DOSLFN.
>
> Yes indeed that did either mask or "fix" the problem. Thanks.
In that case please tell in
Originally to: ALL
I could reproduce this.
it happens in/after findnext()
this error is related to the compiler.
if the source is compiled using TurboC 2.01 the error occures.
compiling the exact same source with TCPP the error is gone.
try www.drivesnapshot.de/freedos/findtcpp.com and
I could reproduce this.
it happens in/after findnext()
this error is related to the compiler.
if the source is compiled using TurboC 2.01 the error occures.
compiling the exact same source with TCPP the error is gone.
try www.drivesnapshot.de/freedos/findtcpp.com and
Originally to: ALL
Hi Troi,
> C:\ELVIS\DOC>find /i "env" e*.htm
> file list ...
> Error reading from drive A: DOS area: general failure
You mean it FIRST checks all files in the current
directory on C: but THEN tries to jump to the A:
drive? That sounds like a bug in the kernel, either
Originally to: ALL
I'm curious as to why FreeDOS is trying to read a:. I've built a VM in
VirtualBox and most things work well, but while digging around looking
for information, I got this after a FIND command.
C:\ELVIS\DOC>find /i "env" e*.htm
file list ...
Error reading from drive A: DOS
Originally to: ALL
Eric,
>> C:\ELVIS\DOC>find /i "env" e*.htm
>> file list ...
>> Error reading from drive A: DOS area: general failure
>
> Does the same bug happen with find /i "env" C:e*.htm
> and with find /i "env" C:\elvis\doc\e*.htm by the way?
Yes it does. I've seen a few posts and
Originally to: ALL
Eric,
In the three cases (mine and your two suggestions) if DOSLFN is loaded
and enabled, there is no sign of a problem.
If DOSLFN is not loaded, I get the error.
If DOSLFN has been loaded, but I disable it (DOSLFN /D), the error returns.
So, DOSLFN seems to "fix" the
Originally to: ALL
Hi Rugxulo and Troi,
>> It could be a rare kernel bug, but my guess is some buffer overflow in the
>> IO95 lib. I think this problem is hidden by enabling DOSLFN.
>
> Yes indeed that did either mask or "fix" the problem. Thanks.
In that case please tell in which situations
Eric,
In the three cases (mine and your two suggestions) if DOSLFN is loaded
and enabled, there is no sign of a problem.
If DOSLFN is not loaded, I get the error.
If DOSLFN has been loaded, but I disable it (DOSLFN /D), the error returns.
So, DOSLFN seems to "fix" the problem, at least from a
Hi Rugxulo and Troi,
>> It could be a rare kernel bug, but my guess is some buffer overflow in the
>> IO95 lib. I think this problem is hidden by enabling DOSLFN.
>
> Yes indeed that did either mask or "fix" the problem. Thanks.
In that case please tell in which situations the bug does
happen
> It could be a rare kernel bug, but my guess is some buffer overflow in the
> IO95 lib. I think this problem is hidden by enabling DOSLFN.
Yes indeed that did either mask or "fix" the problem. Thanks.
> But I personally just avoid Find and use Xgrep instead.
I probably will too as I learn what
Eric,
>> C:\ELVIS\DOC>find /i "env" e*.htm
>> file list ...
>> Error reading from drive A: DOS area: general failure
>
> Does the same bug happen with find /i "env" C:e*.htm
> and with find /i "env" C:\elvis\doc\e*.htm by the way?
Yes it does. I've seen a few posts and such that sound
Hi,
On Jan 16, 2017 11:24 AM, "Eric Auer" wrote:
>
> > C:\ELVIS\DOC>find /i "env" e*.htm
> > file list ...
> > Error reading from drive A: DOS area: general failure
>
> You mean it FIRST checks all files in the current
> directory on C: but THEN tries to jump to the A:
>
Hi Troi,
> C:\ELVIS\DOC>find /i "env" e*.htm
> file list ...
> Error reading from drive A: DOS area: general failure
You mean it FIRST checks all files in the current
directory on C: but THEN tries to jump to the A:
drive? That sounds like a bug in the kernel, either
in the drive status
I'm curious as to why FreeDOS is trying to read a:. I've built a VM in
VirtualBox and most things work well, but while digging around looking
for information, I got this after a FIND command.
C:\ELVIS\DOC>find /i "env" e*.htm
file list ...
Error reading from drive A: DOS area: general
Hi Markus,
no, since i get kick! like i turn the pc on and get kick!
doesn't even try to access the fdd or the hdd i think this
kick! is stored somewhere now in a battery buffered area,
like even if i remove the power plug and then turn it on again,
it goes STRAIGT to kick doesn't show me
Hi
doesn't work to. see above :)
I have run into a problem similar to this problem on my Thinkpad - the
system was refusing to reboot and the power button was putting the
system into suspend mode. My fix was to remove the battery from the
laptop for 60 seconds then put the battery back
hi
this is Eric Auer's MetaKern bootloader that is being used.
Option 1 is 386-specific,
Option 2 is to boot the FreeDOS which is on the diskette.
yup, something like this :)
There it prints KICK! and then expects to find KERNEL.SYS
are you sure KERNEL.SYS file is present on that
23 matches
Mail list logo