Re: Socket files, artype=exustar, errctl=

Hi,

> Joerg Schilling wrote:
> By default, star is in normal "archiver" mode and this is different
> from what people expect for backups.
> ...
> Star is mainly an archiver..... It includes however special
> backup/restore features.
>
>> i wrote:
>>  A small paragraph (positioned quite early in star.1) about
>>  the appropriate choice of archive formats would be helpful. 
> 
> Isn't all this information in the artype= section?

Yes and no.

Yes, as usual with manpages, after i learned the right trick
i can then point to the spots in the page which would have 
told me if i had made the connection in my mind.

No, it did not lead me from -acl protest messages to -dump
or level=0 . I could have been led by the fact that i had
tried level=x -acl successfully before. But that sequence of
events was incidential and cannot presumed when designing
the manpage.

To support my own experience, i quote R.J. who just reported
to use
  -acl H=exustar
Quite the same setting that i developed before learning
about backup mode.


That's why i think that a paragraph about format choice should
be at a prominent place near the start of the manpage.
Additionally, short notes should warn the user at text parts
where one could mistake exustar for the backup mode.

I believe that the right place would be as second paragraph
in FEATURES, after "Star includes the first free" and before
"Star by default uses a fifo".
It should mention archive mode, backup mode, compatibility
issues and full incremental backups, together with pointers
to the options which are appropriate for those usage scenarios. 

Actually that first paragraph in FEATURES is too much into
technical details. On the other hand i understand that it's
about the motivation and central achievements of star. 


Alternatively one could begin the EXAMPLES section with
a spectrum of write command examples. These examples should
then cover above issues archive, backup, compatibility.
Issue "incremental" is well covered by its own paragraph.
A short pointer at the end of FEATURE's first paragraph would
then suffice. Like :
 "See EXAMPLES for the main usage scenarios."

(Actually, EXAMPLES was the first thing i read after DESCRIPTION
and FEATURES. It is full of impressive stunts but leaves out
the bread-and-butter usage of star.)


>>  dump/restore is traditionally an awful, hyper specific
> If you do not use the dump/restore features of star, you do not
> get all features of star.

I hope "-dump" and "dump" share only the name and not
the hardships. :))


> If you like a complete backup, is is the best to use level=0.
> In this case, star forces you to backup the complete filesystem
> and archives even more data about the FS.

That force would be overdone for my purposes.
I need (and hope to have found) a thing between
your concepts of backup and archiver.

I want an archive mith maximum fidelity in
respect to file attributes and types.
But i also want to be free to include and
exclude files and (normally) do not want to be
restricted by the borders of filesystems.

We talked about the risks of live filesystems
and the remaining risks with snapshots. These
risks i want to tackle by exclusion of problem
areas and by specialized partial backups which
cover the excluded parts if backupworthy at all.
Among other things i want to be able to backup
user data as non-superuser. This is not possible
with a whole filesystem which also hosts other
user's data or system files.

So level=0 is not so much what i want.
For API compatibilty reasons i feed my file addresses
into star's stdin (cpio style) and this is really far away
from your level=0 usage scenario, isn't it ?

-dump seems to be the appropriate thing (i hope).


> You cannot archive ACLs if you choose an archive format
> that does not support ACLs.

That's what star told me when i tried and that's
what led me to artype=exustar rather than to -dump.
If i had started my brain after successful  level=x -acl
and made the connection to the historical remark in
the description of -dump ... yeah, then i would have 
understood.


>>  I now understand exustar as a prerequisite for 
>>  premium exactness but not as being at the level where
>>  a user should tune exactness on the first hand.
> 
> I don't understand what you like to say here.

I fiddled with the artype when i should have fiddled
with the backup/archive mode.


> In addition, star includes a powerful way of controlling the
> error handling and star-1.5a66 did even enhance this a lot.

a66 ? Looks like it's time for me to upgrade.
... done (patting my DSL modem).


> INCREMENTAL BACKUPS

As said, that's too monolithic for my intentions.
(I understand the stability advantages of a monolith
but it is so hard to handle in daily life.)


[nostalgy mode]
>> ... PF_UNIX sockets ...
> On which OS did you have problems?

Domain/IX, SunOS, CLIX, HP/UX, IRIX, AIX, ...
The idea already died in design stage because it was not
possible to assure general portability of the program
semantics. IP sockets did work on all acceptable Unixes
in the late 80s. 
No TCP/IP = no yellow cable = no acceptable workstation.
IP sockets provided all functionality and - after all -
brought me into the Internet world 10 years before
i was online for the first time.
(Isn't it great to run a LAN program unchanged over
thousands of kilometers and a dozen routers ?)

[end nostalgy mode]


> I am still in hope to get a dual core opteron as a present from AMD ;-)

I thought its the burner industry which should weight
you up in gold. :))
Within seven years Yamaha sold me two, Lite-On and LG each one.


> With star-1.5a66 you may also tell star to immediately abort on
> unexpected errors.

It might last a while until i explore this.
But i will keep you informed.


>> ... abort too soft ...
> Do you use 'bash' to run the script?

Yes. I confess. 
It's the one which one has to cope with.

I will retry this with ksh (not yet).
(My scripts depend on $($(...)) and thus are not
usable with S.R. Bourne's original shell, i fear.
Nevertheless i take care to test them with both
bash and ksh ... it was a bash-day when i experienced
that soft abort.)


> Star most likely was not interrupted because you did use a broken shell.

Whatever, -no-fifo made it bash-safe.
If a tape is the backup target then there will
be a writer program in charge of doing appropriate
buffering. (Nothing worse than the forward-backward
sound of a starving QIC tape drive.)
I also offer the option to talk my star-wrapper
into using -fifo.


Have a nice day :)

Thomas