<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user">
    <title>gmane.comp.archivers.star.user</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/789"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/788"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/787"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/786"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/785"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/784"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/783"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/782"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/781"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/780"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/779"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/778"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/777"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/776"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/775"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/774"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/773"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/772"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/771"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.archivers.star.user/770"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/789">
    <title>Re: stalling</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/789</link>
    <description>&lt;pre&gt;

Did you try to find out why stdout might be blocked?

What file if connected to the stdout filedescriptor in star?

The write(2) size of 5120 bytes tends to lead to a pipe that is blocked....

Jörg

&lt;/pre&gt;</description>
    <dc:creator>Joerg Schilling</dc:creator>
    <dc:date>2013-04-10T08:45:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/788">
    <title>Re: stalling</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/788</link>
    <description>&lt;pre&gt;Thanks for your response. I ran truss on the two star processes that
got created from one star invocation:

/var/tmp# truss -p 21402
write(1, 0x0814304C, 5120)      (sleeping...)

/var/tmp# truss -p 21403
read(5, 0x08046CFB, 1)          (sleeping...)

Here is the pstack output from 21402:

 fedec317 write    (1, 814304c, 1400)
 fedcc794 _flsbuf  (20, 80b6398, 57, 35303030) + cc
 0808a14e filewrite (80b6398, 803c688, 68, 803c680) + 87
 08089f4b _bflush  (803c680, 803c680, 80991fc, 803c7c0) + 33
 0808a059 js_fprintf (80b6398, 80991fc, 808fa70, 803d690, 2ff90, 0) + 5b
 08066078 vprint   (803daa0, 803daa0) + 246
 08069c86 createi  (803d690, 803d690, 47, 803daa0, 803d680, 803daa0) + 645
 0806b69a put_dir  (803ea50, 803ea50, 3c, 803ee60, fe5e5c00, 803ea40) + 6bc
 08069868 createi  (803ea50, 803ea50, 3b, 803ee60, 803ea40, 803ee60) + 227
 0806b69a put_dir  (803fe10, 803fe10, 36, 8040220, feae9c00, 803fe00) + 6bc
 08069868 createi  (803fe10, 803fe10, 35, 8040220, 803fe00, 8040220) + 227
 0806b69a put_dir  (80411d0, 8&lt;/pre&gt;</description>
    <dc:creator>Ryan Lovett</dc:creator>
    <dc:date>2013-04-10T04:13:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/787">
    <title>Re: stalling</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/787</link>
    <description>&lt;pre&gt;

First a warning: If you exclude parts of the filesystem from a dump, star will 
not be able to "restore" files that have been brought back into the "visible" 
parts of the dump by renaming a a directory that was in the excluded part.

This is because such an action does not set the "ctime" stamp on such files.


Your current statements do not include any information that could help.

The minimal information would be to run truss on both star processes in order 
to get the current state of the processes.

I assume that star is not looping, so this should show a syscall...

Also helpful would be a "pstack" outoput from both processes.

How much data did star already dump before stalling?

Jörg

&lt;/pre&gt;</description>
    <dc:creator>Joerg Schilling</dc:creator>
    <dc:date>2013-04-09T09:03:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/786">
    <title>stalling</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/786</link>
    <description>&lt;pre&gt;With star 1.5.2 on the latest Solaris 10, we are seeing star appear to
stall in the middle of dumping a ZFS snapshot to tape. Attaching dtruss,
iosnoop, and opensnoop to the affected process shows no activity. We
invoke star with:

  star -C /path/to/.zfs/snapshot/20130407 -c -S -acl artype=exustar \
-sparse -time -xdev \
-multivol -wtardumps -new-volume-script=/usr/local/sbin/mtx-next \
errctl=/usr/local/etc/star-errctl.conf \
-not pat=*/.Trash/* pat=*/.cache/* pat=*/.thumbnails/* pat=*/.nfs* \
level=0 fs-name=/path/to blocks=512 file=/dev/rmt/1cn .

I don't believe it is a problem with the tape device since we can kill the
hanging star and run another (on another filesystem) right after which
runs to completion.

Does anything above suggest why the star process stalls or waits?

How can one debug this further?

Thanks for your time,
Ryan
&lt;/pre&gt;</description>
    <dc:creator>Ryan Lovett</dc:creator>
    <dc:date>2013-04-08T21:44:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/785">
    <title>Re: exclude directories</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/785</link>
    <description>&lt;pre&gt;* Message by -Ashley- from Wed 2013-02-27:
 



Change to

/home/zelda/data
/home/zelda/Stuffs

or use

DIRECTORIES="home/zelda "

in combination with -C /
&lt;/pre&gt;</description>
    <dc:creator>Lasse Kliemann</dc:creator>
    <dc:date>2013-02-27T17:35:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/784">
    <title>Re: exclude directories</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/784</link>
    <description>&lt;pre&gt;

Hi, why do you believe that an option will work that was never implemented this 
way by tar?

Star supports patterns since aprox. 1985 and it recently (since 2007) supports 
the -X option from tar (exclude a non-pattern containing list of files located 
in a file).

Star also includes find(1) via libfind since 2004, so you have plenty of ways 
to do what you like.

BTW: this is documented in the man page ;-)

Jörg

&lt;/pre&gt;</description>
    <dc:creator>Joerg Schilling</dc:creator>
    <dc:date>2013-02-26T10:23:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/783">
    <title>Re: exclude directories</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/783</link>
    <description>&lt;pre&gt;

Thank you for the hint, it seems that I added the option name for gtar 
compatibility in 2007 together with -X. Note that in contrary to gtar, there is 
no pattern handling in star for this option.

Jörg

&lt;/pre&gt;</description>
    <dc:creator>Joerg Schilling</dc:creator>
    <dc:date>2013-02-26T10:29:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/782">
    <title>Re: exclude directories</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/782</link>
    <description>&lt;pre&gt;* Message by -Ashley- from Mon 2013-02-25:


It works for me, just tested (version 1.5.1).

Can you explain exactly what you tried to do? (Contents of 
exclude file, location of files, ...)
&lt;/pre&gt;</description>
    <dc:creator>Lasse Kliemann</dc:creator>
    <dc:date>2013-02-26T08:54:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/781">
    <title>exclude directories</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/781</link>
    <description>&lt;pre&gt;Hi there

How can I exclude a few directories?
I have tried using --exclude-from $EXCL_LIST  and listed the directories 
in the said file, but
this does not work?

Thank you in advance!!


&lt;/pre&gt;</description>
    <dc:creator>Ashley</dc:creator>
    <dc:date>2013-02-25T21:29:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/780">
    <title>Re: --one-file-system</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/780</link>
    <description>&lt;pre&gt;

Mount has no --bind option - in special, I know of not a single double dash 
option in mount.


If the struct stat st_dev fiel changes it's value, you passed a mount point.


See man page, star implements -M since before GNU tar exists......

Jörg

&lt;/pre&gt;</description>
    <dc:creator>Joerg Schilling</dc:creator>
    <dc:date>2013-01-09T10:26:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/779">
    <title>--one-file-system</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/779</link>
    <description>&lt;pre&gt;Hi there

I am using "mount --bind ..." in order to give ftp users access to 
specific folders they need, outside of
their home folder. So multiple mounts to the same /data/ folder

Problem is now when I backup it includes multiple copies of these folders.

Does star have a "--one-file-system " equivalent, or do I need to make a 
list
of all the folders mounted with the bind option and put these in an 
Exclude list?

Any other suggestions will be much appreciated!

Thank You in advance!

&lt;/pre&gt;</description>
    <dc:creator>Ashley</dc:creator>
    <dc:date>2013-01-09T09:25:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/778">
    <title>Re: Span filesystem across two tapes</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/778</link>
    <description>&lt;pre&gt;Am 23.12.2012 21:48, schrieb James R. Chavez:


Sorry, but I don't understand the problem.

The script can be written in every language (including JAVA, COBOL, ..)
that is able to change a tape. It only has to do everything we discussed
before - and that's the hard work.

For changing tapes on SOLARIS I have to give up - the last SOLARIS
machine I had was a SPARCclassic - and I think you have a newer one.

GS

&lt;/pre&gt;</description>
    <dc:creator>Gerhard Schneider</dc:creator>
    <dc:date>2012-12-24T09:42:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/777">
    <title>Re: Span filesystem across two tapes</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/777</link>
    <description>&lt;pre&gt;
Hi Ashley,

I thought that that I could only use -multivol interactively..

It says to use it non-interactively I have to use "new-volume-script=script"

Can anyone clarify?

Thanks
Jimmy
CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited.  If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an &lt;/pre&gt;</description>
    <dc:creator>James R. Chavez</dc:creator>
    <dc:date>2012-12-23T23:23:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/776">
    <title>Re: Span filesystem across two tapes</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/776</link>
    <description>&lt;pre&gt;On Sun, Dec 23, 2012 at 10:07 AM, Gerhard Schneider
&amp;lt;gs&amp;lt; at &amp;gt;ilsb.tuwien.ac.at&amp;gt; wrote:


Hi thank you for your reply.

Please see my replies below.

I assume this is an exit code for success..

Yes in sequential/stacker mode. Currently ufsdump spans tapes with "L" option.
Yes but not necessary, we have rotating tape sets.
Library with enough tapes for the week. We send them offsite on Monday
after one week of backups, full + differential.
No need for manual intervention with ufsdump as it automatically spans tapes.
nothing
yes, I have experinented with MTX but since ufsdump spans naturally,
it's not needed.
not necessarily.
solaris 10, star installed. SUN C2 Autoloader LTO3, 8 slot.
If by this time I cannot write my own script I will take up selling AVON.. : D
I really just need the syntax to make it work and I can run with it.

Thanks
Jimmy
CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confident&lt;/pre&gt;</description>
    <dc:creator>James R. Chavez</dc:creator>
    <dc:date>2012-12-23T20:48:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/775">
    <title>Re: Span filesystem across two tapes</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/775</link>
    <description>&lt;pre&gt;Am 23.12.2012 09:07, schrieb James R. Chavez:

As a user of multi-volume star dumps for years I can tell you that the
answer to your question is 42!

A few additional questions to think about

*) Are you using a tape library?
*) Do your tapes have bar codes (and your library a bar code reader)?
*) Are all your tapes in the library or is manual intervention needed
   or required (storage of magazines in a safe)?
*) Should the manual intervention being requested by direct eMail or
   are you using a more complex management system like NAGIOS?
*) What has the operator to do after changing the tape/magazine?
*) Can you control your tape library via mtx (or something similar)?
*) Do you want to interpret SMART results?

A few additional questions like operating system and manufacturer of the
backup system are self-evident..

After answering the questions for yourself you can hire somebody (not
ME) to write such a script for you!

GS

&lt;/pre&gt;</description>
    <dc:creator>Gerhard Schneider</dc:creator>
    <dc:date>2012-12-23T17:07:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/774">
    <title>Re: Span filesystem across two tapes</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/774</link>
    <description>&lt;pre&gt;

$BACKTUPTO=/dev/st0                          # backup device
$DIRECTORIES="/home /data /etc "      # directories to be backed up

  /opt/schily/bin/star -c -multivol -P -f $BACKUPTO $DIRECTORIES


&lt;/pre&gt;</description>
    <dc:creator>Ashley</dc:creator>
    <dc:date>2012-12-23T16:19:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/773">
    <title>Span filesystem across two tapes</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/773</link>
    <description>&lt;pre&gt;Hi,

I have been struggling with my Ufsdump backups for some time now.
Regardless of the blocksize i use I see very little improvement in
speed. I have been looking for a replacement and there are a few
threads out there that claim star is much faster. I have a few file
systems that span multiple LTO tapes. Currently I use ufsdump to span
these large filesystems across multiple takes in a script. I would
like to use star so I have been reading the man page on how to span
tapes and I see "-multivol". However this seems to be an interactive
only option.

Note that  -multivol  is  an  interactive  option  that
          prevents   star  from  being  used  in  non-interactive
          environments.   If  you  like  to  use  it  in  a  non-
          interactive    environment,   you   need   to   specify
          new-volume-script=script in addition in order to  auto-
          mate the media change procedure.


So my question,can anyone on the list share how I can use star tospan
a large filesystem across mul&lt;/pre&gt;</description>
    <dc:creator>James R. Chavez</dc:creator>
    <dc:date>2012-12-23T08:07:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/772">
    <title>Re: star segmentation fault</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/772</link>
    <description>&lt;pre&gt;Joerg, hi there

Thank you for quick reply!!

I installed the latest version from the ftp site you provided. This fixed
the problem. Is now working very well

Untitled Document

Many thanx
Best regards
Ashley


On 2012/11/06 04:33 PM, Joerg Schilling wrote:


_______________________________________________
Star-users mailing list
Star-users&amp;lt; at &amp;gt;lists.berlios.de
https://lists.berlios.de/mailman/listinfo/star-users&lt;/pre&gt;</description>
    <dc:creator>Ashley</dc:creator>
    <dc:date>2012-11-21T20:45:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/771">
    <title>Re: star segmentation fault</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/771</link>
    <description>&lt;pre&gt;Am 06.11.2012 15:54, schrieb Mark:


Another "didn't know it, too.."

Perhaps somebody should tell people to look for schily-XX.tar.bz2 when
looking for star? :-)

GS

&lt;/pre&gt;</description>
    <dc:creator>Gerhard Schneider</dc:creator>
    <dc:date>2012-11-06T17:14:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/770">
    <title>Re: star segmentation fault</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/770</link>
    <description>&lt;pre&gt;
Would you be able to update the Star web page at
http://cdrecord.berlios.de/private/star.html to tell people where to get
the latest version?

The Star web page doesn't mention ftp://ftp.berlios.de/pub/schily/. It
only mentions ftp://ftp.berlios.de/pub/star/ (and
ftp://ftp.berlios.de/pub/star/alpha/, but that only contains pre-1.5.1
versions).

People will naturally think that 1.5.1 is the latest version, with no clue
that there have been any releases since. That's probably why most
distributions' star packages are stuck on 1.5.1.


&lt;/pre&gt;</description>
    <dc:creator>Mark</dc:creator>
    <dc:date>2012-11-06T14:54:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.archivers.star.user/769">
    <title>Re: star segmentation fault</title>
    <link>http://permalink.gmane.org/gmane.comp.archivers.star.user/769</link>
    <description>&lt;pre&gt;

A star version "1.5.1-4.fc13.i686" does ot exist.


Linux distributions are known for frequently introducing bugs into software.

I recommend you to first compile star by your own and check whether this 
problem also appears with an unmodified original source.

The most recent source is in:

ftp://ftp.berlios.de/pub/schily/

There have been many changes since December 2009, when star-1.5.1 was published.

If the problems also appears with the original software, you would need to send 
the whole command line and the location in the code that causes the coredump.

Jörg

&lt;/pre&gt;</description>
    <dc:creator>Joerg Schilling</dc:creator>
    <dc:date>2012-11-06T14:33:57</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.archivers.star.user">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.archivers.star.user</link>
  </textinput>
</rdf:RDF>
