X-Authentication-Warning: delorie.com: mail set sender to opendos-bounces using -f Message-Id: <200407141149.i6EBnVEo020375@delorie.com> From: "Michal H. Tyc" Organization: BTTR Software Date: Wed, 14 Jul 2004 13:48:13 +0200 X-Mailer: Arachne V1.73J4;GPL To: opendos AT delorie DOT com Subject: Re: COPY/MOVE From Mapped Drive MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-2 Content-transfer-encoding: 8bit Reply-To: opendos AT delorie DOT com On Tue, 13 Jul 2004 22:56:38 -0400 (EDT), Gary Welles wrote: > SHARE on the remote system will only cure the problem if the > drives are mapped with PNW. > I normally do not use PNW SERVER and VLM and use only IPX and > DV/X on both machines. The DV/X machines are both client and > server where SHARE's file locking can be an aggravation with > multitasking. I'm totally ignorant on DV/X, but I always thought that multitasking and networking environments are these that SHARE is mainly intended for... > In any event SHARE has had no effect on 4DOS and the DV/X > mapping where it's remote drive TSR maps in individual DOS > windows (secondary shells). In this case 4DOS COPY/MOVE > _from_ remote fails when Novell DOS 7.00 or DR-DOS 7.03 and > not MS-DOS 6.22 and 7.10 are on the client side. As I understand, the remote drive TSR runs on the "client" (local) machine? Is there any difference when you replace DR-DOS with MS-DOS on the "server" (remote) machine? Maybe the DV/X remote drive TSR uses some undocumented MS-DOS functions or data structures, which aren't implemented or aren't 100% compatible under DR-DOS? > This mapping is limited compared to global mapping in DOS > before DV/X, however when I need to act on remote files the > usual means is to open a remote DOS shell or run a remote > application and thus use the additional resources (memory, > CPU, etc.) of the other machine. From the remote shell I can > map my local drives as remote in the remote shell and then > copy _to_ them with 4DOS. But your problem occurs within local shell as well, right? Michal