[EMAIL PROTECTED] wrote: > Up to now, i found a typo and a truncated sentence in the man page > of star-1.4.3 and online in
Any reason to test a version that is outdated since more than 3 years? > http://cdrecord.berlios.de/old/private/man/star.html : > "POSIX tar compatibilitx mode" > "The environment variable As the" > The latter is a two-liner in star.1, beginning at line 2070. Thank you, it seems that nobody found this 3.5 year old typos. > Tests are in progress. I use star as afio alternative by a afio is no real alternative to star for many reasons: - Damaged CPIO archives are much harder to recover than tar archives. - The POSIX cpio format is limited to 8 GB files. The SVr4 cpio format is even limited to 2 GB files. - The CPIO archive format is not a single archive format but a set of completely incompatible different formats. - The POSIX cpio archive format is considered to be outdated since 5 years as is is not possible to cleanly extend the CPIO archive format. The official standard archive format is now an extended tar format called "pax". Star is the first program that supports this archive format and all recent star extensions are based on this format. - Every time afio encounters files that cannot be processed with existing cpio archive formats, it changes the archive format (on the fly) to a nonstandard afio proprietary format that cannot be processed by any other archiver. > wrapper script. star option "list=-" helps to keep that > script small. > Roughly the pipeline looks like this : > my_filelist_generator | \ > star -c -z list=- | \ > my_checksummer | \ > cdrecord ... If you like to do backups, this is a really bad method. For reliable backups, the backup utility needs to have full control over the directory tree. This is not true in case you prepare the filenames from another program. > A question to be RTxy'ed : > Does exit 254 always indicate a incomplete but healthy > archive or are there cases where exit 254 indicates abort ? > (I got that exit value with some unreadable files in the > input list. star produced a sound archive but my own > software counted the outcome as failure because of the > non-zero exit.) The next release will have this text: EXIT STATUS The following exit values are returned: 0 All files were processed successfully. -2 / 254 One or more files could not be processed successfully. -1 / 255 Command line parsing error. >0 Other positive exit codes: The errno of the call that caused the fatal error. > Currently i'm exploring another effect : > $ star tvf /dev/cdrom > star: Archive is compressed, try to use the -z option. > $ star tvzf /dev/cdrom > star: Can only compress files. > Possibly i should stop using old tar's command syntax ? > $ star -t -v -z f=/dev/cdrom > star: Can only compress files. > $ star -t -v -z </dev/cdrom > star: Can only compress files. > Is it a gzip'ed stream at all ? > $ gunzip </dev/cdrom | star tv > ...finally my archive's table of contents... > Yes, it is. Well, star does nothing that cannot be done reliably. As devices need to be handled in a blocked way. This cannot be done when the in/output is run through a zip pipe. Use star | sdd or sdd | star to reblock the data stream in this case. > Next i plan to learn about the incremental features. > Not so much for using them but for comparison with my > own incremental efforts. > (Imitation is the highest form of flattery.) star-1.4 does not support incrementals. with cpio, or a similar program, this is not possible too. > Vanilla tar as found on many antique workstations isn't good enough. > I never evaluated GNU tar for 100% completeness but resort > to good old afio which serves me as Linux backup format since > more than a decade. GNU tar is not reliable enough for backups. Every time, I added new features that supposedly is supported by GNU tar I tested GNU tar too and I always found a bug un GNU tar after less that 5 minutes of testing. > There's a nice feature with afio. It offers a file-by-file > compression with cleartext archive structure. > Very rugged, quite economic. Again: star does not implement things that cannot be implemented in a reliable way. To do this, you need to knoe the compressed size of all files before you start to archive them. If you compress a copy in /tmp, you are limited with the size of the files. If you do it "on the fly", you would need to compress the file two times and still run into big problems when the file changes meanwhile. > For long time backups and extremely important data > my software offers redundancy at the level of the raw > backup data stream. The user may produce several identical > copies of the backup media which get appended a block > checksum list. This list allows to detect damaged parts of > the data stream. For long time backups, you should not use a program like afio that uses a proprietary achive format. Star's archives may be unpacked by any POSIX.1-2001 compliant archiver. If you do this, you only miss the additional meta data from the files and you cannot do an automated incremental restore. > On most user filesytems, ACLs and Extended Attributes are > disabled, anyway. ACLs are enabled by default on the UNIX file system since more than 10 years and cannot even be switched off. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
