Re: Socket files, artype=exustar, errctl=

[email protected] wrote:

> what file types other than PF_UNIX sockets are known
> to raise error condition SPECIALFILE with artype=exustar ?

Star with artype=exustar supports all possible filetypes that
are used on Solaris.

> (With Linux, ext2, ext3, reiserfs, xfs, ... ? ...)

Linux only supports a limited number of file types.
If yyou like to see more different types look at Solaris or
FreeBSD.

Star is prepared to also support whiteout files from FreeBSD
but they have not yet been allowed because I did not yet have
the occasion to test them.


> I get haunted by messages like 
>
>   star: '/dev/log' unsupported file type 'socket'. Not dumped.
>
> which also lead to star exit value 254 (resp. -2) and cause
> my script to raise alarm and point the user upward to
> the backup protocol.
> That protocol looks quite ugly by 28 of above messages.
> It is intended to look appeasing because backup is about
> a calm sleep.

I thought you like to use star to make backups.
Why then do you use star in a mode that is intended for best
portability between different POSIX systems?


> I understand that powerful artype=exustar does not support

It does of course, but you don't want them unless you are doing
real and accurate backups.

> socket files, neither does artype=gnutar which seems to be

GNU tar is limited in the set of supported file types.


> the default (despite the "do not" in man 1 star).
> artype=star does not complain about sockets but the man page
> gives me the impression that exustar is superior otherwise.

The old star format is from 1986 and tries to be a clean extension
on the historic tar archive format from 1978 while being
definitely pre POSIX.1-1988.


> I understand that PF_UNIX sockets are supposed to be removed
> on end-of-service. So after a shutdown or crash they are
> dead trash anyway. A new startup of the related service will
> create the socket again. (Linux: man 7 unix, "NOTES")

Even ufsdump silently omits sockets from the backup....
Star _includes_ them if in backup mode.


> Unless there are any sophisticated tricks with permissions
> which rely on the existence of the predecessor socket file,
> i can imagine no situation where it makes sense to restore
> socket files. So there is no need to backup them.

On a vanilla SVr4, there are no socket in the filesystem.
Sockets reappeared around 1998 when SUSv2 did replace 
the t_* based networking interface by the old socked based
system requiring that dup(2) on a socket works.
As this is only possible if the socket implementation is in
the kernel, Solaris did put sockets back into the kernel and 
did re-introduce socket typed files again althouth even the
*BSD man pages from 1979 mentions socket files as being obsolete and
unwanted....


> I consider to use errctl= with a file containing the line
> SPECIALFILE *
> In a test it worked fine for artype=exustar -acl .

Not needed if you use star for backups....


> Nevertheless the error condition SPECIALFILE does not
> refer explicitely only to PF_UNIX socket files. 

Correct, this is because there is no need to make more distinctions.


> Therefore my question : are there filetypes with exustar
> which are more worth restoring but are not supported ?

Star supports to archive all file types on Solaris if in
backup mode.

> (... and how about artype=gnutar ?)
> I do not want to suppress messages about those other types.

See above, gnutar is limited

> Could one possibly downgrade the "type 'socket'" condition
> from deferred error to a mere notification ? (Or just be
> silent without errctl= file ?)

Why?

If you use star for backups, it archives even sockets.

> Argument driven errctl would be nice anyway, like
>   errctl-line='SPECIALFILE *'
> The need for a file is a bit a rupture in star's usual 
> user interface. 

The errctl= option is mainly used with backups in case you
have no snapshots and need to tell star that e.g. growing log files
are not a problem for a backup. For backups you need to use 
the tardumps=filename option anyway.

BTW: I am just adding new features to the errctl= system
that allows to tell star to abort on specific errors instead
hiding them.

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