From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10111122328.AA19135@clio.rice.edu>
Subject: Re: RESEND: Patch to computer st_blksize in struct stat
To: djgpp-workers AT delorie DOT com
Date: Mon, 12 Nov 2001 17:28:46 -0600 (CST)
Cc: rich AT phekda DOT freeserve DOT co DOT uk
In-Reply-To: <3BF027F7.DEE05D7@phekda.freeserve.co.uk> from "Richard Dawe" at Nov 12, 2001 07:50:15 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> > Calling fixpath just to get the drive letter seems like overkill here.
> > If the in path has a ':' in the second char we could use it; else get
> > the current drive.
> 
> I thought fixpath() would be needed to cope with joined paths, because I
> thought that the source & target of the join could have different block
> sizes. (I have to admit that I can't remember if you can actually have
> joins between different drive letters.)

fixpath does nothing special in drive handling: if the original path
has a drive letter it just copies it to the destination.  If not it
adds one using AH=0x19.  It does call putpath which would translate 
/dev/env components into the string - which might be desirable
(I don't remember the context here).