Quantcast

Re: after

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: after

BlameTroi
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 problem, at least from a user perspective.

This is FD 1.2.

Thanks again.

>>> 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 and in which not, for example with/without having
> DOSLFN loaded :-) It could still be a bug caused by kernel
> limitations which affect LFN file listing more than 8.3?

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freedos-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freedos-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: after

Eric Auer-3
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
in the drive status init or in findfirst / findnext
and to be honest I think that has happened before?

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?

Regards, Eric



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freedos-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freedos-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: after

Eric Auer-3
In reply to this post by BlameTroi
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 the bug does
happen and in which not, for example with/without having
DOSLFN loaded :-) It could still be a bug caused by kernel
limitations which affect LFN file listing more than 8.3?

Cheers, Eric



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freedos-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freedos-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: after

tom ehlert
In reply to this post by BlameTroi
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
www.drivesnapshot.de/freedos/findtc21.com

of course this can be a kernel bug, but as well a turbo library bug,
or some sort of interference between them.

Tom







------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freedos-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freedos-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Loading...