Re: [MiNT] ramdisk bug

[Alan Hourihane <alanh@fairlite.co.uk>]

On Mon, 2010-08-16 at 12:55 +0000, Helmut Karlowski wrote:
> Alan Hourihane wrote:
> 
> > I'm not sure where we're at with this bug, but it definitely sounds like
> > Peter's setup is saving the files to a different location that Peter
> > thinks in 1.17. But in 1.16 it's in the location he expects.
> 
> For me this is fixed with your last ramfs-fix. The files went into the
> root-dir of the current drive before.
> 
> Jo Even Skarstein wrote:
> 
> > Now, is this repeatable with other extractors ? ZIP, LHA, ZOO etc ?
> >
> > Can ARCVIEW (or the other) dump out the actual commandline parameters
> > it's used to spawn the external APP and do the extraction ?
> >
> > As it should be entirely repeatable once we have that.
> >
> > Alan.
> 
> > --------------------------------------------------
> > From: Jean-Luc CECCOLI <Jean-Luc.Ceccoli@wanadoo.fr>
> > Sent: Monday, August 16, 2010 1:35 PM
> > To: <mint@lists.fishpool.fi>
> > Subject: Re: [MiNT] ramdisk bug
> >
> > > Got it! files are extracted to /opt/toswin2/ folder!
> > > Any sense to this ?
> >
> > Most likely a problem with the parameters passed to the unpacker.
> >
> > Jo Even
> 
> 
> I'd like to know how many users encounter this so-called bug using the
> latest mint (and 2in1).
> 
> It's not the commandline.
> 
> 2i1 calls Dsetpath to the target, i.e. cd /ram, or whatever, and that
> may fail, because there is no 'real' drive-letter (like in u:/c/...). It
> tries to cd to /u/ram.

/ram should work just fine, regardless of drive letter. Why does it try
to cd to /u/ram when /ram was requested ?

Alan.