Philip Rowlands <[EMAIL PROTECTED]> ha escrit:
> $ tar --file example.tar --delete etc/alsa/cards/aliases.conf
Does it depend on the location of the member in the archive (at the
beginning/middle/end)?
Regards,
Sergey
Ladislav Michnovi <[EMAIL PROTECTED]> ha escrit:
> I have tested your reproducer and I've got segfault. I recompiled
> cpio 2.9 with your patch but I'm still getting segfault.
> Have I missed something?
No, you have not. The patch is wrong. See my previous post.
Regards,
Sergey
Dmitry V. Levin <[EMAIL PROTECTED]> ha escrit:
> My suggestion is to avoid using alloca() with user controllable size.
> In this particular case, memcpy() call could be optimized out as well.
The proposed patch will make things worse: tar will segfault, because
the passed string is freed after in
Dmitry V. Levin <[EMAIL PROTECTED]> ha escrit:
> I do not suggest to remove xstrdup completely, just replace it with
> xmalloc; nothing more, nothing less.
Yes, indeed, I misread it. Thanks for pointing that out. I have
installed the following patch:
Index: paxlib/names.c
==
Ian <[EMAIL PROTECTED]> ha escrit:
> I have found that sometimes tar will exit with a 0 status for files
> that are not tarfiles.
To be precise, it will silently ignore any files smaller than 512 bytes,
whatever their contents. Thanks for reporting. Enclosed is the fix.
Regards,
Sergey
Index: s
Eric Blake <[EMAIL PROTECTED]> ha escrit:
> It looks like a bug when extracting broken symlinks that point to
> destinations outside the tar'd directory:
It looks, indeed. However, I failed to reproduce it with the CVS
version. Here's what I did:
$ pwd
/tmp/tar
$ ln -s ../nowhere broken
$ tar cf
Philip Rowlands <[EMAIL PROTECTED]> ha escrit:
> I defer to the greater knowledge of the maintainers whether this is a
> real bug in busybox, a real bug in GNU tar, or an unfortunate silent
> corruption because last week I didn't know --blocking-factor existed.
Knowing the blocking factor used wh
Richard Thomas <[EMAIL PROTECTED]> ha escrit:
> It appears that tar is returning 1
> when a file changes when being read (I have verified this by tarring
> the output of tar).
Yes, it does, and it was stated explicitly in the release notice for
version 1.16 (see the NEWS file):
* After creatin
Esin Andrey <[EMAIL PROTECTED]> ha escrit:
> Hi!
> I try to compile tar-1.18 and have one warning:
>
> utf8.c: In function âstring_ascii_pâ
> utf8.c:94: warning: comparison is always true due to limited range of
> data type
This warning reflects the fact that, depending on whether the defaul
Jim Meyering <[EMAIL PROTECTED]> ha escrit:
> tar doesn't build against the latest gnulib.
> Here is a patch to fix that, along with changes to avoid a bunch of warnings:
Thank you. I have installed these changes.
Regards,
Sergey
Na (Anne) Zou <[EMAIL PROTECTED]> ha escrit:
> Yesterday I ran "tar cvfz ../tmp.tgz ../tmp" under i386-Linux, then get
> tmp.tgz successfully. Since I'll take it to customer, I check it in my
> PC, winrar can untar it. But when I run "tar xvfz tmp.tgz" in customer's
> Linux system, it failed with
Selim Albardak <[EMAIL PROTECTED]> ha escrit:
> My system is running tar-1.15.1-5 as per zmanda
For your information, the latest tar version is 1.18. You might consider
updgrading it.
Regards,
Sergey
Christian Weisgerber <[EMAIL PROTECTED]> ha escrit:
> really correct? It has been forwarded to me as a security fix for
> 1.18, but there it causes tar to hang when trying to extract any
> symlink from an archive. This can easily be confirmed by running
> the test suite.
The test suite works fo
Christian Weisgerber <[EMAIL PROTECTED]> ha escrit:
> Take tar 1.18, add the rev. 1.63/1.64 change to src/names.c, run
> make test. It will get stuck here:
>
> 19: extracting symlinks over an existing file
I've tried that. It has passed the testsuite like a charm.
Regards,
Sergey
Arkadiusz Bieniek <[EMAIL PROTECTED]> ha escrit:
> tar -cz -f "/backup/${LABEL}.tgz" --exclude-from ${EXCLUDES_FILE}
> --ignore-failed-read -P -g"$STATUS_FILE" /
What is the contents of ${EXCLUDES_FILE}?
Pozdrawiam,
Sergey
Matthias Koenig <[EMAIL PROTECTED]> ha escrit:
> the patch below seems to be needed to get tar compiled with
> gcc-4.3.
Thank you.
Regards,
Sergey
Nicholas Cole <[EMAIL PROTECTED]> ha escrit:
> A leading / is being included in incremental snapshot rename codes
> when a member name has a leading / and tar removes leading / from
> member names when the archive is created
>
> Is this a bug or am I doing something incorrect?
Yes, it is a bug.
Nicholas Cole <[EMAIL PROTECTED]> ha escrit:
> This patch causes tar to strip leading / from rename codes during
> creation. Can you also patch tar to strip leading / from rename
> codes during extraction? This would prevent odd behaivor when
> extracting an archive created with an unpatched versi
Juhana Sadeharju <[EMAIL PROTECTED]> ha escrit:
> Hello. I have large tar.gz packages in archive DVDs.
> What if the file gets corrupted? Is the whole file
> useless? For example, what happens if one byte is
> altered short after the begin?
This question is not exactly tar-related. Tar does not p
Juhana Sadeharju <[EMAIL PROTECTED]> ha escrit:
> Can gzip data be uncompressed starting from the middle of file? Unknown.
> Can bzip2 data be uncompressed starting from the middle of file? Yes.
Again, you are directing these questions to the wrong address. Tar does
not do any compression decompr
Hello,
I am pleased to announce the release of GNU tar 1.19.
GNU tar is available for download from
ftp://ftp.gnu.org/gnu/tar and the mirror sites worldwide (see
http://www.gnu.org/order/ftp.html for the list of those).
The available files and their MD5 sums are:
d184a969b3c364a89dc70971eac333c
Hendrik Maryns <[EMAIL PROTECTED]> ha escrit:
>
> This seems to be caused because people wanted to be too smart, since a
> bit later it says ‘Kan niet savedir’, which is as strange, but ‘savedir’
> is not translated. Maybe it should be ‘Kan savedir niet uitvoeren’.
>
That's a possible translat
Jan Psota <[EMAIL PROTECTED]> ha escrit:
> Are You going to add LZO (for faster compression) and LZMA
> (for better compression) native handling in TAR (through short options
> and automatic recognition on decompression)?
Yes, sure. I am going to add this feature as soon as possible. I
cannot gua
To begin with, let me remind that we are discussing GNU tar here.
Joerg Schilling <[EMAIL PROTECTED]> ha escrit:
> - POSIX does not forbid long options, it only recommends to use short
> options.
Right. In GNU, long options begin with two dashes, not one. Therefore -7z
is not a long o
Jan Psota <[EMAIL PROTECTED]> ha escrit:
> 'J' (bigger compression than bzip2,
Hmm, nice mnemonics:)
> 'q' (like quick for lzop)?
There are some plans for that letter.
> I would propose [-]q|--lzop and [-]J|--7zip.
FWIW, the CVS version uses --lzma option now.
Regards,
Sergey
Dustin J. Mitchell <[EMAIL PROTECTED]> ha escrit:
> My reading of the documentation, and the lack of a reply to this post:
> http://www.archivum.info/bug-tar@gnu.org/2005-02/msg00011.html
> suggest that this is, more or less, a consequence of tar's design.
Yes, that's right.
> It would seem th
Tim Kientzle <[EMAIL PROTECTED]> ha escrit:
> When reading uncompressed tar archives stored in regular files,
> bsdtar uses lseek() operations to skip over the bodies of
> files.
As a side note, the similar feature in GNU tar is enabled using
--seek option.
Regards,
Sergey
Tim Kientzle <[EMAIL PROTECTED]> ha escrit:
> Is there a reason GNU tar doesn't enable this by
> default for all regular files?
I forgot to implement it :) But I'll fix that soon.
Regards,
Sergey
Bengt-Arne Fjellner <[EMAIL PROTECTED]> ha escrit:
> Problem found.
> buf in sys_exec_info_script was not initialized to zero;
> see patch:
Thank you.
Regards,
Sergey
> You -do- realize that the subject line is not English, right?
Wrong:
"He, being in the vaward, placed behind
With purpose to relieve and follow them,
cowardly fled, not having struck one stroke."
-- William Shakespeare,
Peter Volkov <[EMAIL PROTECTED]> ha escrit:
> Hello. I have problem with running testsuite. Sometimes it's passes
> sometimes not. Below is the relevant output when it fail. If I run
> another time it succeeds. Very strange.
You've forgotten to tell on what operation system and on what filesystem
Peter Volkov <[EMAIL PROTECTED]> ha escrit:
> That's gentoo linux, kernel 2.6.22-gentoo-r8-suspend2, gcc-4.2.2,
> glibc-2.6.1.
What file system was it, please?
--Sergey
Vitaly V. Ch <[EMAIL PROTECTED]> ha escrit:
> when I create compressed tar archive the archive's file is not
> consistent at exit of tar but after exiting child gzip.
Could you explain, please?
-Sergey
Vitaly V. Ch <[EMAIL PROTECTED]> ha escrit:
> On some machines run under slackware 10.2 next test always fail:
>
> for ((i=0;i<1000;i++)); do echo $i >$i; tar cz $i >>file.tgz; done;
> gzip -t -v file.tgz
It should have failed. You cannot glue together two compressed files and
expect the result
Tim Kientzle <[EMAIL PROTECTED]> ha escrit:
> That doesn't quite explain why his second example always
> works for him, though:
Yes, Tim. The actual problem was an obsolete tar version (see my
previous posting).
-Sergey
Jean-Louis Martineau <[EMAIL PROTECTED]> ha escrit:
> > touch 1
> > tar cz 1 > file.tgz
> > ls -al file.tgz
> -rw-rw-r-- 1 martinea martinea 10240 Nov 23 07:32 file.tgz
> > dd if=file.tgz count=1 bs=108 > a.tgz
> > gunzip -t -v a.tgz
> a.tgz: OK
>
> Why the file is 10k in size? Why tar pad
Martin Keegan <[EMAIL PROTECTED]> ha escrit:
> I understand you fixed a problem with the interaction between
> --one-file-system and --listed-incremental around v1.16.
Yes, we did. What version are you using now?
> in my $INC file, doing
>
> tar cpf $OUTPUT --one-file-system --listed-incrementa
Curt Blank <[EMAIL PROTECTED]> ha escrit:
> Is this ever going to be addressed when spanning tapes?
It has been addressed quite a while ago (around v1.16, 2005). Try
--format=pax, it does not have this limitation.
Regards,
Sergey
Curt Blank <[EMAIL PROTECTED]> ha escrit:
> Thank you. Didn't see the --format option when I do a "man tar" but I
> now see it when I do a "tar --help".
Please see GNU tar documentation. The `--format' option is described
in the chapter 8, "Controlling the Archive Format". The infornation is
als
Curt Blank <[EMAIL PROTECTED]> ha escrit:
> Ok, when I try and use --format=pax in my production backups they all
> fail with:
>
> tar: GNU features wanted on incompatible archive format
You are using an old version of GNU tar (prior to 1.16). Please,
upgrade.
Regards,
Sergey
Curt Blank <[EMAIL PROTECTED]> ha escrit:
> Well that's easier said then done. I use applications off the
> distribution to take advantage of the vendors updates and patches.
Why can't you just download it from ftp.gnu.org and compile?
> What version of tar is the minimum I would need for this
=?UTF-8?B?T3phbiDDh2HEn2xheWFu?= <[EMAIL PROTECTED]> ha escrit:
> When you try to update a tar archive which doesn't exist, tar exits with
> an error :
Thanks for reporting. I have installed the following fix:
Index: src/buffer.c
Radek Brich <[EMAIL PROTECTED]> ha escrit:
> Although it'd need some cleaning, I'd like to hear what
> you think about the idea?
Generally speaking, looks nice, except that fstat may fail (e.g. if
stdout is closed) in which case st_stdout would contain garbage.
Regards,
Sergey
Andrew Klaassen <[EMAIL PROTECTED]> ha escrit:
> 'tar cWf' leaves the tape in a different position than
> 'tar cf' does. Compare the expected behaviour to the
Could you test the following patch, please? It is made against CVS
and should apply to v.19 cleanly.
Regards,
Sergey
Index: src/compare
Hello Harald,
> any comments or takers?
Seems a nice idea. I'll install this to CVS.
Regards,
Sergey
Hugh Sasse <[EMAIL PROTECTED]> ha escrit:
> I'm not entirely sure what this means. Does it mean
>
>* the job completed successfully apart from the earlier errors,
> which now give this error exit.
Yes, exactly that.
> Can I tell tar to truncate filenames that are too long (possibly
>
Ken Williams <[EMAIL PROTECTED]> ha escrit:
> A co-worker sent me the following command as a Neat Trick for extracting
> files from whichever tarball they happen to be in:
>
> cat *tar.gz | tar xz -ignoreblocks --files-from f
The option -ignoreblocks is parsed as `-i -g noreblocks',
i.e. `--ig
Andrew Henry <[EMAIL PROTECTED]> ha escrit:
> I perform level0 backup to save file to
> /home, and when i did level2, I still had original tarball from level0
> in /home.
Ah, I see...
> Second problem is still a problem though.
> > Second issue is that tar --list archive.tar is not working fo
Joerg Schilling <[EMAIL PROTECTED]> ha escrit:
> > i.e. `--ignore-zeros --listed-incremental=noreblocks'. The only
>
> This is something I would call an ugly option parser bug.
On the contrary, this is intended behavior, see
http://www.gnu.org/software/tar/manual/html_section/tar_21.html#SEC35
jlh <[EMAIL PROTECTED]> ha escrit:
> Using GNU tar 1.19, I was unable to extract files from a tar
> archive using wildcards when the file name contains a byte
> sequence that is not valid in the current locale.
I tried to reproduce this with tar 1.19 and got:
$ LC_ALL=de_DE tar -tf my.tar --wild
Eric Blake <[EMAIL PROTECTED]> ha escrit:
> It is technically possible to
> create a filter thread or process, whose job it is to create a new output
> pipe, replay the first few bytes that tar already read in determining that
> stdin was compressed, then read the remainder of the original input p
Rodrigo Nery <[EMAIL PROTECTED]> ha escrit:
> Hello to all,
Hi Rodrigo,
My apologies it took me so long to reply.
> Given the following tar command, with multiple --transform options, the
> expected result not occurs.
>
> tar ztvf teste.tgz --transform="s,^producao/,producao2/,g"
>
jlh <[EMAIL PROTECTED]> ha escrit:
> Ok, here's an update. I could track down the cause of this
> problem. In order to match file names to patterns, tar uses the
> fnmatch(3), which is provided by glibc. This happens in
> lib/exclude.c:149:exclude_fnmatch(). fnmatch() is documented to
> return
Bdale Garbee <[EMAIL PROTECTED]> ha escrit:
> One of the users of my Debian tar packages reports that --transform only
> works on symlinks during extraction, not on creation or listing. A
> quick review of the info doc didn't suggest any reason for that to be
> intentional?
Thanks for reporting.
Helmut Waitzmann <[EMAIL PROTECTED]> ha escrit:
> >3) i suggest that the location of the compress/gzip/bzip2/lzma programs
> >be settable at configure time, and that the tar executable uses the PATH
> >only when not set at configure time or not found in the indicated place.
[..]
> Please, don't do
Wagner Lopes Moreira <[EMAIL PROTECTED]> ha escrit:
> [EMAIL PROTECTED]:/media/hdc3/LINUX progs$ tar -vzxf samsutools.tar.gz
> samsutools-20070901-alpha/
> samsutools-20070901-alpha/conf/
> samsutools-20070901-alpha/conf/ppp.setup.example.linux
> tar: samsutools-20070901-alpha/conf/ppp.setup.examp
Tim Kientzle <[EMAIL PROTECTED]> ha escrit:
> In GNU tar 1.19, the pax extended header entry for '.'
> has the name "./PaxHeader./."
[...]
> Generally, '.' is a poor name for something that will
> get extracted as a file by a non-compliant reader.
The name was selected to comply with the pax
Leonard Sitongia <[EMAIL PROTECTED]> ha escrit:
> The new tar on Linux made the situation worse. As before, when it
> finishes reading the first tape, it doesn't prompt for the second
> tape, it just ends.
Have you tried -i (--ignore-zeros) option?
Regards,
Sergey
Piero <[EMAIL PROTECTED]> ha escrit:
> $ tar cfv archive /etc/mail
[...]
> In the first line, the options 'f' and 'v' are inverted, which would
> cause the creation of a 'v.tar' archive.
No, it would not. When using old option style the order of options
is irrelevant. See
http://www.gnu.org/so
Elwood C. Downey <[EMAIL PROTECTED]> ha escrit:
> I have a directory that contains some files. I have a tar file that
> contains many of the same files but not all and some are newer and
> some are older than the existing files. For files that exist both
> already and in the tar, I want to replace
Hi Bdale,
> A bug filed a while back by one of the users of my Debian packaging of tar
> noted that passing pipes via <() in bash on the tar command line had broken,
> and Ingo Saitz later tracked this down to the introduction of closeopen() on
> 2006-07-03, but noted there was no reason given for
Bdale Garbee <[EMAIL PROTECTED]> ha escrit:
> One of the users of my Debian packaging of tar notes tripped over the fact
> that while the definition of option -l changed in 1.15.91 to no longer be a
> synonym for --one-file-system, some of the translated documentation in po/*
> apparently has appa
Joerg Schilling <[EMAIL PROTECTED]> ha escrit:
> This is a problem I've seen many times with GNU tar. When I did see it,
> it was a result of a the way the data structures are defined by GNU
> tar.
If you are referring to the problem illustrated by
ftp://ftp.berlios.de/pub/star/testscripts/README
Joerg Schilling <[EMAIL PROTECTED]> ha escrit:
> If you explain me how you did it, of course
Everything is explained in the ChangeLog, I believe.
Regards,
Sergey
Robert Connolly <[EMAIL PROTECTED]> ha escrit:
> Hello. The attached patch adds a --disable-default-root-preserve configure
> option, so root does not preserve file mode or ownership when
> extracting.
Why is it needed? You can achieve the same effect by running
tar --no-same-permission --no-
Akshay Bajpai <[EMAIL PROTECTED]> ha escrit:
> I am working with Amdocs and found one issue with the tar.
What version of tar are you using?
> Please let me know about:
> 1) The limitation for the maximum number of input files to be
> tarred
None.
> 2) The limitation of maximum siz
Akshay Bajpai <[EMAIL PROTECTED]> ha escrit:
> What version of tar are you using?
> AKSHAY- I don't know how to get the version of tar
Run tar --version
> AKSHAY - If there is no limitation on the number of files we can tar
> then how the tarring failed?
To answer this I need to know the exact
Hi Jean-Louis,
My apologies for being slow with replying.
> Attached patch fix a bug because DIR_IS_NFS return 2 if it is NFS.
Thank you, I have applied it.
> Instead of trying to detect if the device should be used, why not add
> an argument:
> --no-check-device
That's a nice idea. I have
Shaun Cowley <[EMAIL PROTECTED]> ha escrit:
> Errors:failed with return code 2
> i: cannot savedir: invalid argument
What version of tar do you use?
Regards,
Sergey
Chiu, PCM (Peter) <[EMAIL PROTECTED]> ha escrit:
> The output file is over-written by the subsequent volume.
> Is it possible to have the output tar file name to be incremented with a
> number?
Use info script (--info-script option). The environment variable $TAR_FD
contains a file descriptor whe
Chiu, PCM (Peter) <[EMAIL PROTECTED]> ha escrit:
> When I come to the restore, the documentation suggests it is possible to
> treat each volume as a single
Yes, as far as it does not begin with a continuation from the previous
volume, which is just the case with:
> /csupport/script/new-tar-volum
Tim Kientzle <[EMAIL PROTECTED]> ha escrit:
> The following command consistently crashes for me (FreeBSD 6.3):
Thank you. Attached is a fix that I installed in the CVS.
Regards,
Sergey
2008-03-31 Sergey Poznyakoff <[EMAIL PROTECTED]>
* src/create.c (dump_file0): Count
Bdale Garbee <[EMAIL PROTECTED]> ha escrit:
> Hi. My Debian package of tar 1.19 is failing on the hppa (PARISC)
> autobuilders
> with several regression suite failures... tests 26, 32, 36, 40, 42, and 43.
> It
> seems to build fine on all other Debian architectures.
Thanks, but I need testsui
Soeren Sonnenburg <[EMAIL PROTECTED]> ha escrit:
> I was using tar 1.19 and trying to extract a .tar.bz2 which was
> defective. So I had to manually use bzip2recover ending up with several
> thousands of .bz2 files of which most could be decompressed. Now
> concatenating all the files (correct ord
Poor Yorick <[EMAIL PROTECTED]> ha escrit:
> building tar-1.19 with gcc-4.3.0 fails:
>
> gcc -m32 -std=gnu99 -g -O2 -L/path/to/lib -L/path/to/lib64
> -Wl,-rpath,/path/to/lib -Wl,-rpath,/path/to/lib64 -Wl,--enable-new-dtags
> -o
> rmt rmt.o ../lib/libtar.a ../lib/libtar.a(argp-fmts
Mike Frysinger <[EMAIL PROTECTED]> ha escrit:
> just debating whether to back port the lzma updates to tar-1.19 or just wait
> for tar-1.20.
Just wait for tar-1.20. I am going to release it within a couple of
days.
Regards,
Sergey
Hello,
I am pleased to announce the release of GNU tar 1.20.
GNU tar is available for download from
ftp://ftp.gnu.org/gnu/tar and the mirror sites worldwide (see
http://www.gnu.org/order/ftp.html for the list of those).
The available files and their MD5 sums are:
832874d7eea94bfe434c48459cbfda8
Skabuby <[EMAIL PROTECTED]> ha escrit:
> Iâm trying to use tar âC option on a windows machine and I get the
> following error:
[...]
> my tar version is 1.12.msdos cause I havenât found a newer one.
That version is 11 years old! Please upgrade to something newer. The
recent version of GN
Hi Andrew,
> I upgraded to a newer version of my distro that has tar 1.19 and now my
> level 1 and level 2 incrementals do not work anymore, instead they do a
> full level 0 backup.
On the first backup, tar needs to convert existing snar files to new
format, supplying default values for missing f
Nigel Kukard <[EMAIL PROTECTED]> ha escrit:
> I backed up a directory with mode permissions with... tar
> -cvf /tmp/test.tar /vservers
Sorry, but the output you've included doesn't show any directories
having 0 mode:
> drwxr-xr-x root/root 0 2008-04-25 17:02 vservers/.pkg/
> drwxr-
H.Merijn Brand <[EMAIL PROTECTED]> ha escrit:
> It looks like 'genfile' either spews more or less info than what
> testsuite expects,
It is unable to create files on these system. The following output:
+10242 10240
means that genfile attempted to create a file 10240 bytes long, but the
resultin
H.Merijn Brand <[EMAIL PROTECTED]> ha escrit:
> File opened 0x7b011c58, off: 0
> File seeked, off: 2
> W 00 @ 2
[..]
> So obviously fseeko () (and.or fseek ()) are severely borked when
> called as first call after fopen (), even if seek_offset == 0.
It is broken for sure, but I doubt if it i
H.Merijn Brand <[EMAIL PROTECTED]> ha escrit:
> For the time being? It does no harm (IMHO) and only guards against old,
> unsupported or non standard-conforming systems, nor does it break tar.
Perhaps I didn't express myself well enough. All you say is true. What I
meant is that the patch avoids
[Cc-ing to bug-tar].
> VMS has files that the information on how to interpret the structure
> is stored in the file header, not the file it self.
>
> Currently gnu tar is not recording this information, and I am trying
> to determine a portable way to record it.
>
> The best hack that I can come
Hi Phil,
> Hi,
>
> The attached patch speeds up the performance of --exclude by using
> hashes (speed gains are seen when using large exclude lists).
You mean for non-wildcard patterns, don't you?
> Is there any chance of getting this included into tar?
Please allow me some time to revise the
> dvd_01/exp1-1/2-2004-1168X-104.zip
> tar: Unerwartetes Dateiende im Archiv.
> tar: Unerwartetes Dateiende im Archiv.
> tar: Nicht behebbarer Fehler: Programmabbruch.
Your archive is incomplete. It ends somewhere within
2-2004-1168X-104.zip. There hardly anything you can do about it.
Regards,
Se
Hi Dan,
> The --exclude-vcs flag excludes version control files from systems such
> as CVS, Subversion, and git; it would be very useful if the flag also
> excluded files from Mercurial, Darcs, and Bazaar. Those three are
> popular VCS's and Bazaar is now a GNU project.
>
> The patch below adds t
Petr Sumbera <[EMAIL PROTECTED]> ha escrit:
> When using -M option for creating multi volume archives, tar can
> produces bad archives (archives which tar cannot extracted again).
Thanks for reporting. Please find attached a patch.
Regards,
Sergey
Index: src/buffer.c
==
Kevin Day <[EMAIL PROTECTED]> ha escrit:
> So, some time again there was discussion on adding both LZO and LZMA.
> LZMA recently made it in, but LZO has not yet merged
I added it to CVS (except for the proposed -q option, which is reserved
for another purposes).
Regards,
Sergey
Marek Kielar <[EMAIL PROTECTED]> ha escrit:
> 1. I encountered a bug while making my own test using multi-volume - I
> provide a test case and I propose a solution at least for this case.
Thanks for reporting. The proposed solution is incorrect, it breaks
several testcases. I have installed a p
Hi Enric,
> I'm using GNU tar version 1.20 for executing incremental backups.
>
> I don't dare to flag it as a bug but I'm a little bit confused with the
> following use case so that any help will be very appreciated.
It is a bug, indeed. Please, find attached a fix.
Thanks for reporting.
Reg
Hi Rich,
> After some time (may be a few files, may be one hundred) my script's
> attempts to untar files fail with exit status 2. I have scoured the
> web for an explanation of exit status 2 and only found one comment
Possible exit codes of GNU tar are described in section 3.1 of the
manual. Y
Paul Fee <[EMAIL PROTECTED]> ha escrit:
> I would expect both first.tar and second.tar to have
> the same contents. The problem is first.tar doesn't
> list file "two". However examining the contents of
> the file reveals that "append2.tar" has been added,
> but the content is not retrievable.
Y
Tim Kientzle <[EMAIL PROTECTED]> ha escrit:
> This approach is necessarily a little slower than the
> GNU tar --concatenate option, but it gives you a lot
> more flexibility. I thought the folks on this list
> might find the approach worth considering.
It is a very interesting approach. What if
Vincent Belaïche <[EMAIL PROTECTED]> ha escrit:
> I downloaded GNU tar version 1.20 and I trie to make it under Mingw on
GNU tar won't compile on Mingw. Use cygwin if you want to compile it on
Windows.
Regards,
Sergey
Hi Marek,
> Hi, I am attaching patch for tar 1.20 which add support for bzr VCS
> system, can you apply it for next tar release, please?
Thank you, these changes are already in CVS.
Regards,
Sergey
Juan Cordoba <[EMAIL PROTECTED]> ha escrit:
>This is using GNU tar 1.20:
[...]
>$ tar cvf z.tar z\\r
>tar: z\r: Cannot stat: No such file or directory
I cannot reproduce this. Running this command with tar 1.20 correctly
adds z\r to z.tar.
Regards,
Sergey
Jan-Benedict Glaw <[EMAIL PROTECTED]> ha escrit:
> If you strace it, you see that the '\r' decoded to ^M and that's what
I have misread the initial post then, because I thought that \r *does*
stand for ^M. If you mean backslash followed by 'r', than you'll have to
either quote the whole combinati
suman <[EMAIL PROTECTED]> ha escrit:
>I created the myarchive.zip using a zip utility, directly zipped; no
>tar is used here.
It is a plain zip archive, use unzip to extract from it.
>is it not allowed to list/unzip files using tar when the compression is
>done by zip?
GNU tar
Jan-Benedict Glaw <[EMAIL PROTECTED]> ha escrit:
> GNU tar gets the file name byte-by-byte exactly as it is on-disk or as
> it would be returned by readdir().
It is not relevant in this case, because the name is given explicitly
in the command line and is therefore subject to unquoting by tar (if
1 - 100 of 1183 matches
Mail list logo
