🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

3 total messages Started by Mark Plotnick Wed, 06 Jan 1993 01:23
multi-hop uucp implies -C?
#2795
Author: Mark Plotnick
Date: Wed, 06 Jan 1993 01:23
16 lines
1125 bytes
Under SunOS 4.1.1, "uucp x host1!host2!y" generates a command that
starts with "uux -C".  Is the "-C" really necessary?  We have a user
here who tried to send out 100 copies of a 6MB file via multi-hop uucp,
and our disks didn't have anywhere near 600MB of space.  Would it be OK
if uucp gave uux the -C option only if uucp was itself given the -C
option?

	Mark Plotnick
	mp@allegra.att.com

P.S. has there been any work toward implementing a sort of
multicasting, in which a single uucp command line can specify that a
file should be copied to multiple destinations?  In the above case,
virtually all the 100 copies were being sent to the same "host1", and it
would be a win to just send the 6MB once and then have host1 execute a
uucp command to send to the 100 destinations.
Re: multi-hop uucp implies -C?
#2802
Author: Ian Lance Taylor
Date: Thu, 07 Jan 1993 01:48
38 lines
2295 bytes
mp@allegra.att.com (Mark Plotnick) writes:

>Under SunOS 4.1.1, "uucp x host1!host2!y" generates a command that
>starts with "uux -C".  Is the "-C" really necessary?  We have a user
>here who tried to send out 100 copies of a 6MB file via multi-hop uucp,
>and our disks didn't have anywhere near 600MB of space.  Would it be OK
>if uucp gave uux the -C option only if uucp was itself given the -C
>option?

If you mean that uucp did an exec of "uux -C", then the -C was
certainly not necessary (although on some systems uucp does a -C by
default, so passing -C to uux by default would be correct; I don't
know about SunOS).

However, if you mean that the above uucp command somehow requested a
remote execution of ``uux -C'' on host1, then the -C is definitely
necessary.  If uux on host1 was invoked without -C, then the file
would have to exist somewhere for uux to copy it.  But if that were
the case, who would delete it?

>P.S. has there been any work toward implementing a sort of
>multicasting, in which a single uucp command line can specify that a
>file should be copied to multiple destinations?  In the above case,
>virtually all the 100 copies were being sent to the same "host1", and it
>would be a win to just send the 6MB once and then have host1 execute a
>uucp command to send to the 100 destinations.

This would be fairly straightforward.  You could make
    uucp file --to host1!host3!file1 --to host1!host2!file2
execute the following on host1
    uucp -C file --to host3!file1 --to host2!file2
Of course, the uucp running on host1 would have to recognize the --to
flag.
-- 
Ian Taylor | ian@airs.com | First to identify quote wins free e-mail message:
`` `The world can grow into an ordered place where all are equal before
    the law.  And the law is just.  Honest.  Without graft.'
   `Is that so important if you are starving?' ''
Re: multi-hop uucp implies -C?
#2810
Author: Chris Lewis
Date: Sun, 10 Jan 1993 05:22
57 lines
3216 bytes
In article <6071@comton.airs.com> ian@airs.com (Ian Lance Taylor) writes:
>mp@allegra.att.com (Mark Plotnick) writes:

>>Under SunOS 4.1.1, "uucp x host1!host2!y" generates a command that
>>starts with "uux -C".  Is the "-C" really necessary?  We have a user
>>here who tried to send out 100 copies of a 6MB file via multi-hop uucp,
>>and our disks didn't have anywhere near 600MB of space.  Would it be OK
>>if uucp gave uux the -C option only if uucp was itself given the -C
>>option?

>However, if you mean that the above uucp command somehow requested a
>remote execution of ``uux -C'' on host1, then the -C is definitely
>necessary.  If uux on host1 was invoked without -C, then the file
>would have to exist somewhere for uux to copy it.  But if that were
>the case, who would delete it?

To make it abundantly more obvious: when the uuxqt used to invoke
the "uux" on the remote system completes, it deletes all the data files
associated with the job.  If you didn't give the -C, the file would
not be there to copy to the next machine when uucico gets around
to try sending it.  This is one of the first things people discover
when they try to write uucp-style remote print programs...

[Like the jackass ones stock on 3b1s.  It uux's the request,
then explicitly uucps the file across into public in a separate
job.  Turkeys.  If uuxqt runs on the remote machine before the
uucp completes (ie: you have multiple connects), the print fails because
the file ain't there yet.  3b1 lp is thoroughly busted.]

>>P.S. has there been any work toward implementing a sort of
>>multicasting, in which a single uucp command line can specify that a
>>file should be copied to multiple destinations?  In the above case,
>>virtually all the 100 copies were being sent to the same "host1", and it
>>would be a win to just send the 6MB once and then have host1 execute a
>>uucp command to send to the 100 destinations.

>This would be fairly straightforward.  You could make
>    uucp file --to host1!host3!file1 --to host1!host2!file2
>execute the following on host1
>    uucp -C file --to host3!file1 --to host2!file2
>Of course, the uucp running on host1 would have to recognize the --to
>flag.

There's several approaches that don't need modified uucps.  Ie:
"uuto" (uucp) the file into public on host1, then invoke a lot
of these:
	uux host1!uucp public/file host2!...
(with the appropriate quoting) Then you only have one copy, but it
won't be automatically deleted.

Or, write a shell script on host1 that does the multi-cast, and
invoke that remotely.  Still have the problem of deleting the file
afterwards.
-- 
Chris Lewis; clewis@ferret.ocunix.on.ca; Phone: Canada 613 832-0541
Psroff 3.0 info: psroff-request@ferret.ocunix.on.ca
Ferret list: ferret-request@ferret.ocunix.on.ca
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads