already wrote the
filename in another attribute then...
(Thinking back we might want to handle retro-compatibility and handle
archives made with existing tar versions over changing the way we code
output; so maybe always preferring GNU.sparse.name over path without
relying on order would be a better solution ?
Thanks,
--
Dominique Martinet
Hi,
Dominique Martinet wrote on Thu, Jun 09, 2016 at 01:22:53PM +0200:
> (For archive digging purpose, this looks a lot like
> http://lists.gnu.org/archive/html/bug-tar/2010-11/msg00095.html ; except
> that the file name must contain utf8/non-valid ASCII component)
>
> We
n /tmp, the added file will be tmp/b.txt but you are
matching /tmp/b.txt
This will work, even if it's not pretty (replace the first / of `pwd` by
a ^ anchor):
$ tar rf a.tar --add-file=$(pwd)/b.txt --transform=s,$(pwd | sed -e
's:^/:^:')/,aaa/,
--
Dominique Martinet
h when it does work, I
personally don't think the speedup of not opening the file is worth it
precisely for the problems listed in the mail you quoted wrt. recent
modifications not necessarily propagated immediately...
Thanks,
--
Dominique Martinet
10:12 A/B/C/D/foo link to A/B/C/D/foo
Cheers,
--
Dominique Martinet
Hi!
Sergey Poznyakoff wrote on Mon, Jun 15, 2020 at 09:21:03PM +0300:
> Please, apply the following patch:
>
> http://git.savannah.gnu.org/cgit/tar.git/patch/?id=63712973c77ede016d859760b18d272bd175fd8e
Thanks for the quick fix!
It's probably not bringing in much new info but it appears to work
Nikos Tsipinakis wrote on Mon, Jul 27, 2020 at 11:41:30AM +0300:
> 2. The build directory should be in a 9p filesystem (in a VM)
> 3. Kernel version should be >=5.6 (it doesn't error on 4.19)
<9p maintainer hat on>
Probably >5.6 (strict), the patch which broke this is 52cbee2a57[1]
("9p: read onl
Paul Eggert wrote on Mon, Jul 27, 2020 at 11:38:34AM -0700:
> On 7/27/20 6:33 AM, Dominique Martinet wrote:
> >It's interesting to see an application actually does open regular files
> >with O_NONBLOCK; when this was discussed in the pull request[2]
> >basically the agre
Paul Eggert wrote on Wed, Aug 05, 2020:
> On 8/5/20 11:47 AM, Nikos Tsipinakis wrote:
> >Can you elaborate? I can't find a code path that loses the errno.
>
> full_read reads a partial block and then tries to read again. The
> second read fails with errno == EIO. full_read then returns the
> numbe
Paul Eggert wrote on Wed, Aug 05, 2020:
> On 8/5/20 2:58 PM, Dominique Martinet wrote:
> >if the second read fails with EIO then at that point in the loop ret < 0
> >and full_read returns -1.
>
> Are you looking at the same source code I am? There is no "ret < 0&q
Hi,
Daniel P. Berrangé wrote on Tue, Jul 20, 2021 at 06:14:53PM +0100:
> > > When attempting to read a file (other than a pipe or FIFO) that supports
> > > non-blocking reads and has no data currently available:
> > >
> > > - If O_NONBLOCK is set, read() shall return -1 and set errno to
> >
Ingo Brückl wrote on Mon, Apr 18, 2022 at 09:31:51PM +0200:
> Get bash-5.1.16.tar.gz from https://ftp.gnu.org/gnu/bash/.
>
> Gunzip it.
>
> Extract the original: tar xf bash-5.1.16.tar && mv bash-5.1.16 bash-org.
>
> Remove lib/glob from bash-org: rm -r bash-org/lib/glob.
>
> Now delete lib/glo
Timothe Litt wrote on Thu, Dec 01, 2022 at 04:14:42PM -0500:
> The attached "hardlink_strace.txt" comes from a simplified command to reduce
> volume, but it should show the same syscalls:
>
> ( cd / && strace 2>hardlink_strace.txt tar -cf - bin/awk bin/bash
> >/dev/null )
The fstatat64 structs r
13 matches
Mail list logo