Re: [MiNT] ramdisk bug

["Helmut Karlowski" <helmut.karlowski@ish.de>]

Am 15.08.2010, 14:27 Uhr, schrieb Peter Slegg <p.slegg@scubadivers.co.uk>:


> > This is the reason:
> >
> > Dsetpath(/u\ram\): returning -33
>
> Cheers everyone, hopefully this can be ironed out.

Seems it's not that easy. Must be inside ramfs. I get weird Dsetpath-calls  
when I extract into /ram. I have a symlink to /ram in the twoinone-dir and  
get:


pid  16 (TWOINONE): Dsetpath(D:\TWOINENG.151\RAM\)
pid  16 (TWOINONE): Dsetpath(D:\TWOINENG.151\RAM\)
pid  38 (tw-call): Dsetpath(U:\PROC)
pid  38 (tw-call): Dsetpath(\f\usr\gem)

pid  16 (TWOINONE): Dsetpath()										<- this fails (empty path)

pid  39 (toswin2): Dsetpath(/d\)									<- files go to d:
pid  39 (lzh): Dsetpath(U:\PROC)
pid  39 (lzh): Dsetpath(\d)

...

Using another dir as target:

pid  16 (TWOINONE): Dsetpath(D:\TWOINENG.151\DOC\)
pid  16 (TWOINONE): Dsetpath(D:\TWOINENG.151\DOC\)
pid  16 (TWOINONE): Dsetpath(D:\TWOINENG.151\DOC\)
pid  42 (tw-call): Dsetpath(U:\PROC)
pid  42 (tw-call): Dsetpath(\f\usr\gem)

pid  16 (TWOINONE): Dsetpath(\TWOINENG.151\DOC)						<- this is right

pid  43 (toswin2): Dsetpath(/d\TWOINENG.151\DOC\)					<- files to correct  
dir
pid  43 (lzh): Dsetpath(U:\PROC)
pid  43 (lzh): Dsetpath(\d\TWOINENG.151\DOC)
pid  16 (TWOINONE): Dsetpath(D:\TWOINENG.151\DOC\)


I *guess* the false Dsetpath-call comes from ramfs, but I have no  
knowledge of it.

Maybe toswin uses the old procfs to get cwd of a process and something  
changed.

The extracted files are on d:.

Currently I don't have the time to trace this.

--
Helmut Karlowski