delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/2004/07/13/22:59:39

X-Authentication-Warning: delorie.com: mail set sender to opendos-bounces using -f
Message-Id: <QQqxfn13048.200407140258@mr4.ash.ops.us.uu.net>
Date: Tue, 13 Jul 2004 22:56:38 -0400 (EDT)
From: Gary Welles <gary AT wellesway DOT com>
To: OpenDos <opendos AT delorie DOT com>
Subject: Re: COPY/MOVE From Mapped Drive
Reply-To: opendos AT delorie DOT com

On 2004-07-13 Matthias Paul wrote:

> Depending on what criteria 4DOS uses in order to determine if
> a drive is remote or local, it may be possible . . .
> I don't recommend it.

4DOS identifies my local CD-ROM drive as "remote" and copying
from it is not a problem.  As Matthias suggests, it's likely
not as simple as I first thought.

> While there is a good rational for 4DOS first locking the file,
> if this can cause problems elsewhere, I would recommend adding
> a 4DOS.INI directive to make this configurable for those how
> don't want it for some reason or the other, but given their
> recent policy changes I doubt they will go for it. It's a pity...

I've reached that conclusion as well.  The result is that 4DOS
regardless of underlying DOS may lock itself out of copying
from who knows what remote system or gadget.  They may be
taking a narrow view of what a server might be.

> Well, many (if not most) disk copy tools use old (and long
> depricated) methods how to open, read or write files. . . .

Perhaps I misspoke, I meant _any_ other file copy utility
works: command.com, 4DOS 7.00 and earlier, XCOPY, anything
that will copy a file from one drive to another.

> Hm, if the problem is down to not using SHARE, is there a reason
> why you don't load it?  . . .

Michal Tyc asks the same question.

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.

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.

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.

I'll keep looking for any explaination of the DV/X System
Monitor's "ISW R" and "ISF R" file modes.  Much of DV/X
assumes you have a UNIX Systems Administrator to explain
things.

-- Gary Welles

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019