[Bug-tar] xattr support from Fedora

. In the near future, pNFS will have a similar desire to be able to restore the file layout from a backup before the data is written to the server(s). Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.

Re: [Bug-tar] patches for acl, xattrs, and selinux support

be at least somewhat portable between high-end filesystems. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.

Re: [Bug-tar] patches for acl, xattrs, and selinux support

On Feb 02, 2009 23:41 -0800, Tim Kientzle wrote: Andreas Dilger wrote: If all of the xattrs are backed up, there is still a whitelist for the restore step, and in the worst case the user will have to update to a newer tar (or edit the code and recompile) to restore their data. Ideally

Re: [Bug-tar] tar fails to preserve hard links with --remove-files

to save the second-last link to the file, mark the hash table entry with delete on next link, and when the last link is found unlink both of them at once. That would avoid hash lookups for 99% of the files in the archive (if assuming typical hard link ratios). Cheers, Andreas -- Andreas Dilger Sr

[Bug-tar] [PATCH] fix overflow in code_ns_fraction()

it to this value Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. tar-1.22-code_ns-overflow.patch Description: Binary data

Re: [Bug-tar] [PATCH] fix overflow in code_ns_fraction()

On 2010-02-05, at 02:42, Kamil Dudka wrote: On Friday 05 of February 2010 09:48:00 Andreas Dilger wrote: If the on-disk nanoseconds count happens to exceed 999,999,999 then code_ns_fraction() will overflow the 9-character array and segfault. While this shouldn't happen normally, it can happen

Re: [Bug-tar] [PATCH] fix overflow in code_ns_fraction()

. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.

Re: [Bug-tar] Tar short read

On 2011-09-27, at 12:28 PM, Sergey Poznyakoff wrote: Kevin Fox kevin@pnnl.gov ha escrit: What about SIGSTOP/SIGCONT? I don't believe they can avoid those. SIGSTOP cannot be caught, blocked, or ignored. It is used only by debuggers. Isn't it also used by Ctrl-Z in bash, and then bg/fg

Re: [Bug-tar] Tar short read

On 2011-09-27, at 1:48 PM, Sergey Poznyakoff wrote: Kevin Fox kevin@pnnl.gov ha escrit: Thats not how I read that function: size_t safe_rw (int fd, void const *buf, size_t count) { enum { BUGGY_READ_MAXIMUM = INT_MAX ~8191 }; for (;;) { ssize_t result = rw (fd, buf,

Re: [Bug-tar] Tar short read

On 2011-09-27, at 2:38 PM, Andreas Dilger wrote: On 2011-09-27, at 1:48 PM, Sergey Poznyakoff wrote: Kevin Fox kevin@pnnl.gov ha escrit: Thats not how I read that function: size_t safe_rw (int fd, void const *buf, size_t count) { enum { BUGGY_READ_MAXIMUM = INT_MAX ~8191

Re: [Bug-tar] Tar short read

On 2011-09-27, at 11:53 PM, Paul Eggert wrote: If I understand this patch correctly, it has an effect only on hosts where SSIZE_MAX INT_MAX. But there are no such hosts in practice. So this patch addresses only theoretical issues, right? There are a couple of fixes in the patch: - The

Re: [Bug-tar] tar and file meta data....

On 2011-11-01, at 2:08 AM, Sergey Poznyakoff wrote: Linda A. Walsh g...@tlinx.org ha escrit: so... plans for tar? Support for POSIX ACLs is in my todo list. I cannot give you any exact timeline, though. Is there any plan to include the xattr/ACL patches from RHEL6 tar? Possibly it was

Re: [Bug-tar] tar auto detect compression

On 2012-01-14, at 2:35, Sergey Poznyakoff g...@gnu.org.ua wrote: Mark Krenz m...@suso.com ha escrit: Really? In 25+ years they've never released a man page? No, and there are no plans of doing so either. Tar is fully documented in texinfo format. The manual is included in the

Re: [Bug-tar] tar auto detect compression

On 2012-01-14, at 8:36 AM, Sergey Poznyakoff wrote: Andreas Dilger adil...@dilger.ca ha escrit: Seriously, although this topic looks more fit for bug-texinfo than for bug-tar, you seem to have a very obsolete version of the info viewer and I'd suggest you to upgrade it, because (all answers

Re: [Bug-tar] Tar's --xattrs | --selinux | --acls listing feature

On 2012-05-03, at 6:10 AM, Pavel Raiskup wrote: Something like that looks reasonable. One major comment, though, is that the output of tar should be parsable, i.e., it should be possible to look at the output, figure out what format it is, and parse it reliably. The current format doesn't

Re: [Bug-tar] Colorized output for GNU tar discussion

On 2013-05-06, at 9:56, Tim Kientzle t...@kientzle.com wrote: On May 6, 2013, at 6:46 AM, Marek Kielar wrote: Colorizations made using piping to external tools suffer from lack of semantic information about the output. Take colordiff for example - in many places it parses (regex's) the

Re: [Bug-tar] Who maintains the tar manual pages distributed with Ubuntu?

Unfortunately, the tar maintainers have taken the stance that because this is a GNU project it should use GNU Info instead of a man page, so they refuse to include the existing man page that has been offered to them. As it stands, the distros maintain the tar man page separate from the package.

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

> On Jul 6, 2016, at 10:33 AM, Joerg Schilling > wrote: > > "Austin S. Hemmelgarn" wrote: > >> On 2016-07-06 11:22, Joerg Schilling wrote: >>> >>> >>> You are mistaken. >>> >>> stat /proc/$$/as >>> File: `/proc/6518/as' >>>

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

On Jul 2, 2016, at 1:18 AM, Pavel Raiskup wrote: > > There are optimizations in archivers (tar, rsync, ...) that rely on up2date > st_blocks info. For example, in GNU tar there is optimization check [1] > whether the 'st_size' reports more data than the 'st_blocks' can hold

Re: [Bug-tar] Detection of sparse files is broken on btrfs

On Jan 22, 2018, at 10:47 AM, Joerg Schilling wrote: > >> On Jan 22, 2018, at 3:28 AM, Joerg Schilling >> wrote: >>> If you still don't understand this, I recommend you to try to write an in >>> kernel filesystem

Re: [Bug-tar] Detection of sparse files is broken on btrfs

> On Jan 8, 2018, at 11:50 AM, Joerg Schilling > wrote: > > Paul Eggert wrote: > >> On 01/08/2018 09:41 AM, Joerg Schilling wrote: >>> POSIX explains that st_blocks counts in units of DEV_BSIZE. >> >> That's not required by the

Re: [Bug-tar] Detection of sparse files is broken on btrfs

On Jan 9, 2018, at 10:02 AM, Tim Kientzle wrote: >> Paul Eggert wrote: >> >>> POSIX does not require that st_nblocks remain constant across any system >>> call. It doesn't even require that it remain constant if you merely call >>> stat twice on the same

Re: [Bug-tar] [PATCH] Remove nonportable check for files containing only zeroes

On Jan 10, 2018, at 4:50 AM, Pavel Raiskup wrote: > > On Wednesday, January 10, 2018 3:42:52 AM CET Mark H Weaver wrote: >> From da922703282b0d3b8837a99a9c7fdd32f1d20d49 Mon Sep 17 00:00:00 2001 >> From: Mark H Weaver >> Date: Tue, 9 Jan 2018 20:16:14 -0500

Re: [Bug-tar] [PATCH] Remove nonportable check for files containing only zeroes

On Jan 23, 2018, at 11:32 PM, Mark H Weaver <m...@netris.org> wrote: > Andreas Dilger <adil...@dilger.ca> writes: > >> On Jan 23, 2018, at 1:44 AM, Mark H Weaver <m...@netris.org> wrote: >>> Andreas Dilger <adil...@dilger.ca> writes: >>&g

Re: [Bug-tar] Problem with gnu tar and ZFS on Linux

On Jun 21, 2018, at 9:23 AM, Pieter Bowman wrote: > > We have been using gnu tar with amanda to backup our ZFS filesystems > on Solaris (both SPARC and x86) for more than 10 years. We take a ZFS > snapshot (destroying the previous snapshot if it exists), run amanda > pointing to the snapshot

Re: [Bug-tar] use optimal file system block size

On Jul 18, 2018, at 9:03 AM, Ralph Corderoy wrote: > > Hi Christian, > >> $ stat -c %o data/blob >> 2097152 > ... >> **tar** does not explicitly use the block size of the file system >> where the files are located, but, for a reason I don't know (feel free to >> educate me), 10 KiB: > >

Re: [Bug-tar] Detection of sparse files is broken on btrfs

On Jan 17, 2018, at 9:49 PM, Tim Kientzle <t...@kientzle.com> wrote: >> On Jan 17, 2018, at 1:09 PM, Andreas Dilger <adil...@dilger.ca> wrote: >> >>> So is there some other way to quickly identify sparse files so we can avoid >>> the SEEK_HOLE scan for n

Re: [Bug-tar] [PATCH] Remove nonportable check for files containing only zeroes

On Jan 23, 2018, at 1:44 AM, Mark H Weaver <m...@netris.org> wrote: > Andreas Dilger <adil...@dilger.ca> writes: > >> On Jan 20, 2018, at 5:06 PM, Mark H Weaver <m...@netris.org> wrote: >>> Yes, on Btrfs I reliably see (st_blocks == 0) on a recently written

Re: [Bug-tar] [PATCH] Remove nonportable check for files containing only zeroes

On Jan 23, 2018, at 2:49 PM, Mark H Weaver wrote: > > Joerg Schilling writes: > >> Mark H Weaver wrote: >> Now many bytes have been written past the hole? >>> >>> Did you read my entire message? The answer to your

Re: [Bug-tar] Suprising behavior of extract with --xattrs

On Jun 3, 2019, at 2:27 PM, Brian Murray wrote: > > When enabling extended attribute support in a tar file (--xattrs) all > extended attributes are stored in the archive, however when the same archive > is extracted only the user.* extended attributes are extracted. To have all > the extended

Re: [Bug-tar] Suprising behavior of extract with --xattrs

On Jun 12, 2019, at 12:15 PM, Brian Murray wrote: > > On Wed, Jun 12, 2019 at 10:32:22AM -0700, Brian Murray wrote: >> On Mon, Jun 10, 2019 at 05:49:49PM -0600, Andreas Dilger wrote: >>> On Jun 3, 2019, at 2:27 PM, Brian Murray wrote: >>>> >>>> When

Re: Tar doesn't handle short reads

I think the proper behavior here is to return the bytes actually read, then retry the rest of the read. If there is a permanent error then it can be returned from the next read. It doesn't make sense to return an error if you don't have to... Cheers, Andreas > On Sep 26, 2020, at 08:19, Nikos

project ID support?

I'm wondering if anyone has tried to do backup/restore of project IDs for a filesystem? Both ext4 and XFS support project IDs, but AFAIK tar does not backup and restore the project IDs of the files. Back before tar supported xattrs, there was the ability to use getfattr to backup the xattrs

Re: Inconsistent list output

On Sep 8, 2022, at 13:01, Paul Eggert wrote: > > On 9/8/22 12:25, Ingo Brückl wrote: >> I'm talking about the Unix >> UserID/GroupID with a historical maximum of 8*characters* each! > > I see no such limit in 7th Edition Unix. The only limit I see is around 500 > bytes for user and group