We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now


NLM/Server based copy

tannhof asked
Medium Priority
Last Modified: 2008-02-01
I am taking care of a dozen servers (4.1, 4.11) that are off site.  Recently, we needed to copy/move some directories from one volume to another at a single remote site.  Both volumes have long name space support.  Does anyone know of an NLM based copy that I can run through RCONSOLE and support long file names?  We are trying to copy 500 meg to 1 gig of data.  Just something quick and dirty to copy/move data...  Thoughts are VCOPY from Vinca (does it support long file names?).    
Watch Question

As you may have seen, Novell's free TOOLBOX.NLM (nifty otherwise) won't do long names, docs in fact say " Issue 1: Only supports DOS name space. Investigation into
               support of long names surfaced many bugs and limitations
               in the current API that made Long name support unfeasible."

Can you run your backup/restore remotely?  If it supports long names and lets you restore to a different volume?   ArcServe can do, I believe.



Your on the right track with toolbox.nlm but as stated it does not support long names.

We currently have ArcServe 5.1 on the server (it will be upgraded to 6.1 by end of August).  The point is I don't want to make this a multistep process, i.e. backup, restore, verify vs copy, verify.  The tape method moves the data twice, disk > tape and then tape > disk.  Second to that, screen refresh from RCONSOLE is quick compared to screen refresh from ArcServe Manager console.

If it is all on the same server you can login to the server as a
user with the rights to the server and use ncopy to copy/move the

Map a drive to root of each volume, then from one drive issue the ncopy command.
using M: as source directory and N: as the destination
ncopy <source directory>  n:\<destination directory> /s /e
if you wanted a move then issue a deltree <source directory>
Do this for each directory [structure] you want to copy/move.
After you are done use Novell's TCOPY to copy trustee assignments
to the new location.  Get TCOPY from:
You can create a batch file to do this ifbyou want to automate this.
Another option is purchase a third party solution.


NCOPY is way off track.  The data is on one server but at a remote location.  NCOPY marches that data back and forth over the WAN and that just doesn't cut it.  

ArcServe has a function COPY which will do the copy but waiting for the manager screens at the workstation GUI to update just takes forever.  I'm looking for an NLM I can run at the console of the server through RCONSOLE
i.e "copy123 <source> <destination> /s /e /v" (all subs, empty, verify).  With this sort of solution, the data stays at the remote site and I only see screen updates.  Also, copying the gig of data will be very FAST.  Transfering rights is easy as only one group uses the data.
Can you suggest a 3rd party NLM that will do this??

I think you are wrong as NCOPY knows if the source and destination is on the same server so the workstation is bypassed.
Novell's Tcopy as I mentioned earlier.  Ncopy doesn't see
long filenames.

Do you use a Win 95 or Win NT at the Admin station ?

There is a utility called jcmd.nlm that is a dos command shell for netware, give it a shot.
found at the following link
It will work on 4.1x Give it a shot

Do you have any NT Workstations out at the site? If so, it is nasty but it works well... do this.
Change the Schedule Service to login with a user with high enough rights to Read and Write to the locations on the server you need.
Start the Schedule Service, you set and start it with Server Manager from another nt workstation. If you don't have sufficent rights to do it, first net use a drive to the nt workstation and connect as the local administrator on the workstation.
Then type this command...
at \\remoteworkstation 12:00 /interactive c:\winnt\system32\xcopy.exe \\remoteservername\vol\dir\dir\*.* \\remoteservername\vol1\dir\dir /s/e

from at to /s/e is one line
that will schedule a job for the remote machine to copy the files from ...\vol\ to ...\vol1\ but the traffic will only go over their network segment.

If you don't have an NT (3.51 or 4) workstation there, I am wasting my breath :) or fingers as it may be...

If the data source and data is on the same server, then, NCOPY will copy the data directly from source to destination.

Only the filenames (status) will be sent to the workstation.

- have you called Vinca or tried their free download to see if VCOPY supports long file names?

- have you checked to see if Arcserve lets you run a script or procedure from the server console?...it just might!    You might even be able to create a job file at your PC, copy it to your remote server, & run it via RCONSOLE!

- if Arcserve's slow workstation GUI is a bummer for remote use, try a decent remote control software package that'll make it work quicker....ReachOut from Stac, PCAnywhere from Symantec, etc, etc.   Many have free trials for you to download, and efficient ways to send&cache GUIs.



To paulnic:  Stayed late and tried ArcServe copy.  Manager screens were at least updating and not pausing.  Did ~750 Meg in 27 minutes plus ~3 minutes waiting for Arcserve Manager screens.  So total in about ~30 minutes.  Long names and rights supported, of course!!  Other than having to wait for off hours to get decent response over the WAN from the ArcServe Manager screens, this seems the best solution.  I have used ArcServe since ver 4 and totally forgot about the copy util.  If no one else comes up with an NLM based copy meeting my original question by Monday (7/13) 8:00 P.M., lock it and you'll get the points.

To jstegall:  Tested NCOPY some more.  I did the same ~750 Meg (see paulnic above) with NCOPY.  2 hour 27 minutes later it finished.  Confirmed nothing else was running at the server i.e backup etc.  Forget XCOPY or XCOPY32, it will take them days across the WAN.  NCOPY is just slower.  While AcrServe copy was running the server was at ~15-20% utilization and responded to my requests just fine.  This was also true with NCOPY but it took a lot longer.  Compare to the Wayneb solution below which was almost as fast as ArcServe but lacking long name support and utilization was still <20%.  One last test was an NCOPY running from my workstation to a local (LAN attached) server (4.11 patched).  VOL1\test1 to VOL2\test1.  2 minutes.  Now the second part to this test was doing the same copy on a server at a remote site across a 56K link from my workstation.  Servers are identical down to the BIOS and NLM.  (We create a working solution and clone it for remote sites.)  It took 3 and a half minutes for the same files.  So YES YOU ARE RIGHT that NCOPY does not send the whole file but it does send something back from the server causing the slow down.  Probably a parity check...    
VOL1\test1 to VOL2\test2

To ACScomm:  I have both available and use both. ???

To Wayneb:  Fast copy if you unload ArcServe, Groupwise, and Cheyenne Antivirus.  But no long file name support.  It took about ~35 minutes to copy the ~750 Meg (see paulnic & jstegall above).

To thomasda:  Missing the point.  The copy will send data from the server\vol1 to the workstation then back to the server\vol2.  An NLM based copy will NOT send data across the wire.  This is what I want due to the amount of the copy.  I also don't need a scheduled copy.  My goal is to copy and prune data to another volume.  It will need to occur at seven more remote sites.  

TO ALL:  Let me rephrase my question.  If these were NT Servers, I could go the server console; open a command prompt, explorer, etc; copy a ton of files from one local volume to another local volume and not one bit of data from the copy would ever hit the LAN/WAN.  On Netware, load an NLM and execute a copy from one volume to another....NO DATA FROM THE COPY EVER HITS THE LAN/WAN.
Wayneb and paulnic I think have the idea...


To paulnic:  I am trying VCOPY at the moment.  It looks 8.3 only.  But, Vinca said they are going to sell this product as a standalone and it WILL support long names then.  That WILL be then, this is now.  Slap in the face of reality.  
No spare machines available at the remote site for remote control %>(.  
Monday by 8, no one else comes up with an NLM the points are yours, just lock the question.  Your in the lead!!
Try solution from Novell: Novell Replication Services!

Additional information about Novell Replication Services 1.21 and a copy of it's beta can be accessed at http://www.novell.com/nrs.

Thanks for the thorough info & responses....your NCOPY wan vs local test, among others, is good data for us all.

Vinca better hurry.  Their press release says the standalone VCOPY (list at $199 for one server, via Vinca e-commerce) is supposed to be ready for download by 7/15, i.e., tomorrow!



To Vitali:
  I tried NRS but I can only get it to copy from one server to another.  I am looking for a copy that stays local on the server that will allow me to copy from volume to volume with no lan traffic.

To paulnic:
   Please lock the question.  50 pts to you!!

Did you try JCMD or FSMIRROR which can be downloaded from:
JCMD is a DOS like shell for the server console,  FSMIRROR is an
NLM that replicates data from one (or more ) servers directory paths to a target server. It works in the background.
I did not think of this at first.

There are other utilities:
Copy.nlm is a server utility to copy files between servers (without involving any clients).
NWCC Allows you to manipulate files in the DOS partition and NetWare partition without taking the server down.


To jstegall:  jcmd does not support long file names.  fsmirror moves data from one server to another.  I am moving/copying data on the same server just different volumes.  So far the best solution is ArcServe COPY.  It is slow to setup and get going, but after that it flies...
Unlock this solution and get a sample of our free trial.
(No credit card required)
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a sample view!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.