Mail Archives: opendos/2004/07/13/18:45:10
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
--
<mailto:Matthias DOT Paul AT post DOT rwth-aachen DOT de>; <mailto:mpaul AT drdos DOT org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org
"Programs are poems for computers."
- Raw text -