X-Authentication-Warning: delorie.com: mail set sender to opendos-bounces using -f Date: Tue, 13 Jul 2004 23:56:34 +0200 From: Matthias Paul Subject: Re: COPY/MOVE From Mapped Drive To: opendos AT delorie DOT com Message-id: <000001c4692a$6e26dc80$c03dfea9@atlantis> Organization: Aachen University of Technology (RWTH), Germany MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Reply-To: opendos AT delorie DOT com On 2004-07-12, Gary Welles wrote: > Would it possible to flag a remote drive as local to overcome > a problem with 4DOS? Depending on what criteria 4DOS uses in order to determine if a drive is remote or local, it may be possible (by patching some internal data structures or hooking some interrupt functions) or not. However, doing so may confuse other disk tools, so I don't recommend it. > I have been unable to copy or move files from a remote drive > with 4DOS. According to JP Software, beginning with v7.01, > 4DOS will no longer copy from remote unless it can first lock > the remote file. 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... > It is easily worked around as _any_ other copy utility will > work regardless. Only 4DOS locks itself out (details below). Well, many (if not most) disk copy tools use old (and long depricated) methods how to open, read or write files. Most disk copy tools are not even network aware - 4DOS is. This has some advantages, but as we see now also some disadvantages. > Mapping with Novell Personal Netware, files won't be locked > unless SHARE.exe is installed on the remote system. Without > SHARE on the remote host: Hm, if the problem is down to not using SHARE, is there a reason why you don't load it? After all, it is a rather small system extension typically occuping not more than 5 Kb. (If you had DOS use the HMA, you could even load SHARE into the HMA, so you wouldn't loose any memory at all, but I guess, you have reserved the HMA for exclusive use by DESQview/X, haven't you?) > Using DESQview/X's remote drive TSR to map drives 4DOS fails > only when run on DR-DOS: > > C:\COPY_LOC>copy e:\copy_rmt\trial.doc > e:\copy_rmt\trial.doc => c:\copy_loc\trial.doc > Access denied "e:\copy_rmt\trial.doc" > 0 files copied I'm not familiar with this tool. Have you tried using it with older DR-DOS versions, in particular DR DOS 6.0 or Novell DOS 7? In case it would work under one of them, this may give hints on where the problem is, and in case of Novell DOS 7 or OpenDOS 7.01 working, I may even know a fix for DR-DOS 7.02 and higher. > With 4DOS on MS-DOS 7.10, the remote DV/X DR-DOS machine > reports the files were opened in Mode "ISF R" with 4DOS and > "ISW R" with DOS XCOPY: > > 4DOS: COPY d:\create.com > > Filename Handles Mode Attr Date Time Owner > CREATE COM 1 ISF R ...... 01/07/99 07:03a 0c58 > > > DOS: XCOPY d:\dconvrt2.exe > > Filename Handles Mode Attr Date Time Owner > DCONVRT2EXE 1 ISW R ...... 01/07/99 07:03a 0c58 I'm afraid, I'm not a DV/X expert at all. Do you have any documentation in regard to the meaning of "ISF R" and "ISW R"? ('R' probably stands for opened for read, but you can open files in a multitude of ways, so I could only guess about the other letters. 'F' for fixed, 'W' for write?) Sorry to not be of much help... Greetings, Matthias -- ; http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org "Programs are poems for computers."