home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!pmafire!news.dell.com!swrinde!cs.utexas.edu!hellgate.utah.edu!cc.usu.edu!jrd
- From: jrd@cc.usu.edu
- Newsgroups: comp.unix.sysv386
- Subject: Re: kermit alternatives
- Message-ID: <1992Aug28.103845.58482@cc.usu.edu>
- Date: 28 Aug 92 16:38:45 GMT
- References: <l9g6biINN44v@phad.hsc.usc.edu> <1992Aug23.180723.58340@cc.usu.edu> <Btnu6G.AI2@chinet.chi.il.us>
- Organization: Utah State University
- Lines: 26
-
- In article <Btnu6G.AI2@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes:
- > In article <1992Aug23.180723.58340@cc.usu.edu> jrd@cc.usu.edu writes:
- >> Performance depends strongly on a) which Kermits are being run, and
- >>b) how they are configured.
- >
- > Is there any way to use MSDOS kermit as a transport for a full-machine
- > backup? With the unix version you can pipe cpio or tar's output
- > through a pair of kermits to either duplicate the files or store them
- > on a remote device, but since MSDOS pipes use temporary files that
- > isn't a practical way to copy the whole machine.
- >
- > Les Mikesell
- > les@chinet.chi.il.us
- --------
- It's a good thought (file time/date stamps being preserved etc) but
- it won't work quite the way one might like. The first reason is Kermits to date
- do not recurse into subdirectories (even the concept is foreign on many
- systems) and the other is they don't create subdirectories during file
- transfers. What one needs to do is archive the local system on the local
- system, thereby preserving all the system-specific file/directory/ownership/etc
- information, and then send the flat file across with Kermit. The same is
- true with other cross platform backup schemes: something has to understand
- the details of the source file system in great depth and preserve them. When
- storing on a foreign file system the only safe approach is the usual
- container-file method (flat file, byte stream fashion, a la mag tape).
- Joe D.
-