Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!cwjcc!hal!ncoast!allbery From: allbery@ncoast.UUCP (Brandon S. Allbery) Newsgroups: comp.unix.questions Subject: Re: tar frustration (was Re: relative pathname question!) Message-ID: <12243@ncoast.UUCP> Date: 16 Aug 88 16:48:17 GMT References: <1670003@hpcilzb.HP.COM< <5762@super.upenn.edu< <1414@valhalla.ee.rochester.edu< <2858@ttrdc.UUCP< <7056@conexch.UUCP> Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery) Followup-To: comp.unix.questions Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 26 As quoted from <7056@conexch.UUCP> by root@conexch.UUCP (Larry Dighera): +--------------- | This is so simple that it makes me feel like I don't understand the problem. | If you want tar to take the names of the files it is to put into the archive | from a file which contains the names of the files, just do this: | | tar cvf /dev/whatever `cat file_of_names` | | You can generate file_of_names with find just like is normally done with | cpio. Ain't UNIX grand? +--------------- But what happens when your file_of_names is > 5120 characters? The exec syscall enforces this limit, you can't code around it. I suggest PD tar or afio (PD cpio); the latter could be modified (incompatibly, but it would work) to support larger inode numbers and such. In fact, I would modify afio for larger dev_t's and ino_t's, then force AT&T to modify cpio compatibly: they will have to face both issues sooner or later, and most likely sooner with STREAMS networking (need *lots* of minor devices and remote or local filesystems could be big). ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc