From owner-freebsd-bugs Sat Oct 19 5:10: 6 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACF2837B401 for ; Sat, 19 Oct 2002 05:10:03 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CA0143E6E for ; Sat, 19 Oct 2002 05:10:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id g9JCA3x3033769 for ; Sat, 19 Oct 2002 05:10:03 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id g9JCA3tQ033768; Sat, 19 Oct 2002 05:10:03 -0700 (PDT) Date: Sat, 19 Oct 2002 05:10:03 -0700 (PDT) Message-Id: <200210191210.g9JCA3tQ033768@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: abc@anchorageinternet.org Subject: Re: gnu/44196: tar (sort option) Reply-To: abc@anchorageinternet.org Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR gnu/44196; it has been noted by GNATS. From: abc@anchorageinternet.org To: Giorgos Keramidas Cc: Subject: Re: gnu/44196: tar (sort option) Date: Sat, 19 Oct 2002 12:01:18 GMT see end of email. these solutions do not work as expected. so - i still say it is a fairly critical 'deficiency' bug in tar - that it cannot archive sorted files without an extensive command line as contained herein (and again, this method fails in the sense that owner/group/permission data gets lost, and also, empty directories are not saved), and that the ability to create a sorted archive are very important for the reasons cited herein. > > > > >Number: 44196 > > > > >Category: gnu > > > > >Synopsis: tar (sort option) > > > > >Originator: Joe Public > > > > >Release: i386 FreeBSD 4.7-RELEASE > > > > >Organization: no org > > > > >Environment: > > > > >Description: > > > > tar is LONG overdue for a sort option. > > > > >How-To-Repeat: > > > > find -s/xargs/tar is a kludge and doesn't > > > > preserve owner/perms nor empty directories. > > > > > > What exactly is it that you are trying to do? IMHO, tar(1) does a very > > > good job of preserving file access attributes, when presented with the > > > right command-line parameters.. > > > > rm 2>&- "$I.tar; "find -s "$I" \! -type d | \ > > xargs tar rvf "$I.tar" && gzip -f9 "$I.tar" && \ > > mv "$I.tar.gz" "$I.tgz" > > > > this is the only way i know to create a *.tgz archive > > of a directory tree (you are forced to use tar's "append" > > mode to accomplish such a task). and as previously stated, > > this method of using tar does not preserve owner/group/permissions, > > and does not archive empty directories. > > OK, then, how about tar(1)'s -T (or -I, or --files-from) option? :) > Something like.. > > find -s "$I" \! -type d > files.lst > tar -czf "$I.tgz" -T files.lst > > Or, even a bit simpler, using the standard Unix convention that '-' > as a file name means the standard input (or output, as appropriate): > > find -s "$I" \! -type d | tar -czf "$I.tgz" -T - > > Would that work for you? > > G'luck, > Peter * -T !!! * * works great :) :) :) thanks! * i don't know how i missed that option. * thank you, and i apologize for wasting your * time on that ... thanks. actually - these solutions do not work. upon testing these solutions, i have determined that: for some reason, tar(1) will not archive files in the sorted order passed to it by find(1). tar(1) takes the files passed to it, and archives them in tar's own sense of order. * * * importance ---------- i have heard that the order is not important in the past - but this is untrue. creating sorted archives is important for many reasons. some quickies i can think of off the top of my head are: 1) makes finding files in the listing of archives easier/simpler. 2) gives you a better idea of how far along an extraction is. 3) in the case of archive corruption, it insures "order" to the point of corruption, which may be important, for example: a) you have "frames", or other sequence of files/images, if the archive corrupts, you would like to at least have an ordered set to the point of corruption. b) you create some new files - if the archive corrupts, you don't want them at the end of the archive, which is where they will be without sorting. sorting ensures a higher likelihood that new files you created will be in the middle, ahead of the corruption in the archive. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message