Thread View: comp.mail.uucp
3 messages
3 total messages
Started by Mark Plotnick
Wed, 06 Jan 1993 01:23
multi-hop uucp implies -C?
Author: Mark Plotnick
Date: Wed, 06 Jan 1993 01:23
Date: Wed, 06 Jan 1993 01:23
16 lines
1125 bytes
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?
Author: Ian Lance Taylor
Date: Thu, 07 Jan 1993 01:48
Date: Thu, 07 Jan 1993 01:48
38 lines
2295 bytes
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?
Author: Chris Lewis
Date: Sun, 10 Jan 1993 05:22
Date: Sun, 10 Jan 1993 05:22
57 lines
3216 bytes
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