Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: jsdy@hadron.uucp (Joseph S. D. Yao)
Newsgroups: comp.std.unix
Subject: Re: tar stop at mount points
Message-ID: <8068@ut-sally.UUCP>
Date: Sun, 17-May-87 15:15:20 EDT
Article-I.D.: ut-sally.8068
Posted: Sun May 17 15:15:20 1987
Date-Received: Tue, 19-May-87 06:24:10 EDT
References: <8046@ut-sally.UUCP> <8018@ut-sally.UUCP> <8024@ut-sally.UUCP>
Sender: std-unix@ut-sally.UUCP
Reply-To: jsdy@hadron.uucp (Joseph S. D. Yao)
Organization: Hadron, Inc., Fairfax, VA
Lines: 37
Approved: jsq@sally.utexas.edu (Moderator, John Quarterman)

From: jsdy@hadron.uucp (Joseph S. D. Yao)

In article <8046@ut-sally.UUCP> you write:
>From: daveb@rtech.uucp (Dave Brower)
>
>In article <8024@ut-sally.UUCP> jsdy@hadron.uucp (Joseph S. D. Yao) writes:
>>In article <8018@ut-sally.UUCP> rbj@icst-cmr.arpa writes:
>>>I would also like to see an option not to cross mount points ...
>>		.. this is awfully hard to do unless you are willing
>>to break modularity by sticking info about the FS into programs
>>which have no need to know about it whatsoever.
>Hmmm.  Since stat(2) returns
>               dev_t  st_dev; /* device inode resides on */
>it should be easy enough to see when you've crossed a device boundary,

Jim (rbj) has mentioned this, and this is of course correct.  I'd
been thinking of a much more elaborate schema.  This is still in fact
new information that 'find' hadn't needed before; but since 'find'
already has to be somewhat sophisticated about the file system,
this isn't such a bad breach of modularity as I'd imagined.  Now,
however, think what you'd have to do (e.g.) to add an option to
'cp' not to copy across device boundaries ...  (rbj had wanted this
capability widely transplanted.)

What I'd been thinking of was something on the order of:
	find / \( -fs /usr -o -fsd /dev/rdsk/ra11 \) -a -print
which is truly terrible to implement.  (Don't anyone flame me
for using archaic "-a"s: current 'find' accepts them, and old
'find' requires them.)
-- 

	Joe Yao		jsdy@hadron.COM (not yet domainised)
	hadron!jsdy@{seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM}
{arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy
     {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

Volume-Number: Volume so] fation our