On Wed, Oct 30, 2019 at 12:08:09PM +1100, matthew green wrote:
> nullfs is terrible. i've always known it has the potential
> to double-cache some file when accessed on both sides.. but
> i recently had a problem where nullfs mounted system was
> stopping ffs from freeing deleted files. i
Joerg Sonnenberger writes:
> On Thu, Oct 24, 2019 at 06:56:57AM +0700, Robert Elz wrote:
> > Date:Wed, 23 Oct 2019 23:30:47 +0200
> > From:Joerg Sonnenberger
> > Message-ID: <20191023213047.ga73...@bec.de>
> >
> > | (1) Abuse of symlinks to shuffle the tree
On Thu, Oct 24, 2019 at 10:17:17PM +0300, Valery Ushakov wrote:
> On Thu, Oct 24, 2019 at 05:26:41 +0200, Martin Husemann wrote:
>
> > Deal with this properly in sysinst would mean:
> >
> > 1) run a script like:
> > rm -f /tmp/list
> > for s in *.${suffix}
> > do
> >for dir in $( tar tvf
On Thu, Oct 24, 2019 at 05:26:41 +0200, Martin Husemann wrote:
> Deal with this properly in sysinst would mean:
>
> 1) run a script like:
> rm -f /tmp/list
> for s in *.${suffix}
> do
>for dir in $( tar tvf "$s" | egrep '^d' | awk '{ print $9}' )
>do
> readlink "$dir" && echo
On Thu, Oct 24, 2019 at 06:56:57AM +0700, Robert Elz wrote:
> Date:Wed, 23 Oct 2019 23:30:47 +0200
> From:Joerg Sonnenberger
> Message-ID: <20191023213047.ga73...@bec.de>
>
> | (1) Abuse of symlinks to shuffle the tree somewhere else. IMO whoever
> | wants to do
On Thu, Oct 24, 2019 at 06:56:57AM +0700, Robert Elz wrote:
> Date:Wed, 23 Oct 2019 23:30:47 +0200
> From:Joerg Sonnenberger
> Message-ID: <20191023213047.ga73...@bec.de>
>
> | (1) Abuse of symlinks to shuffle the tree somewhere else. IMO whoever
> | wants to do
Date:Wed, 23 Oct 2019 23:30:47 +0200
From:Joerg Sonnenberger
Message-ID: <20191023213047.ga73...@bec.de>
| (1) Abuse of symlinks to shuffle the tree somewhere else. IMO whoever
| wants to do that should be using null mounts and deal with it
| appropiately in
On Wed, Oct 23, 2019 at 09:41:30PM -, Christos Zoulas wrote:
> In article <20191023213047.ga73...@bec.de>,
> Joerg Sonnenberger wrote:
> >On Wed, Oct 23, 2019 at 04:58:05PM -, Christos Zoulas wrote:
> >> I am not advocating for either, perhaps we should just add -P to the
> >> extraction
In article <20191023213047.ga73...@bec.de>,
Joerg Sonnenberger wrote:
>On Wed, Oct 23, 2019 at 04:58:05PM -, Christos Zoulas wrote:
>> I am not advocating for either, perhaps we should just add -P to the
>> extraction and get over it :-)
>
>From what I can tell there are two completely
On Wed, Oct 23, 2019 at 04:58:05PM -, Christos Zoulas wrote:
> I am not advocating for either, perhaps we should just add -P to the
> extraction and get over it :-)
>From what I can tell there are two completely separate issues:
(1) Abuse of symlinks to shuffle the tree somewhere else. IMO
On Wed, 23 Oct 2019, Christos Zoulas wrote:
I am not advocating for either, perhaps we should just add -P to the
extraction and get over it :-)
This one gets my vote! :)
++--+---+
| Paul Goyette | PGP Key fingerprint:
In article <20191022200319.ga83...@bec.de>,
Joerg Sonnenberger wrote:
>On Tue, Oct 22, 2019 at 08:00:35PM +0200, Christian Groessler wrote:
>> "tar" had an option to delete files which it is about to extract before
>> extraction. Wouldn't this solve the "symlink" issue at hand? What am I
>>
On Tue, Oct 22, 2019 at 08:00:35PM +0200, Christian Groessler wrote:
> "tar" had an option to delete files which it is about to extract before
> extraction. Wouldn't this solve the "symlink" issue at hand? What am I
> missing?
See the SECURITY section in the man page. Both -U and -P are ways to
On 2019-10-22 17:43, Robert Elz wrote:
Date:Tue, 22 Oct 2019 14:33:27 - (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:
| Well, one of the use cases is when we don't have enough disk space in the
| same partition, so that will not work
Date:Tue, 22 Oct 2019 14:33:27 - (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:
| Well, one of the use cases is when we don't have enough disk space in the
| same partition, so that will not work out.
No, I meant symlinks in the archive, not
In article <19306.1571753...@jinx.noi.kre.to>,
Robert Elz wrote:
>Date:Tue, 22 Oct 2019 14:27:39 +0200
>From:Joerg Sonnenberger
>Message-ID: <20191022122739.ga86...@bec.de>
>
> | Extraction of entries in streamable formats happens in isolation. The
> | archiver
On Tue, Oct 22, 2019 at 07:26:05AM +0200, Martin Husemann wrote:
> On Tue, Oct 22, 2019 at 06:37:44AM +0700, Robert Elz wrote:
> > Date:Mon, 21 Oct 2019 21:20:25 +0200
> > From:Joerg Sonnenberger
> > Message-ID: <20191021192025.ga33...@bec.de>
> >
> > | That said,
In article <20191022052605.ga...@mail.duskware.de>,
Martin Husemann wrote:
>On Tue, Oct 22, 2019 at 06:37:44AM +0700, Robert Elz wrote:
>> Date:Mon, 21 Oct 2019 21:20:25 +0200
>> From:Joerg Sonnenberger
>> Message-ID: <20191021192025.ga33...@bec.de>
>>
>> | That
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig
> On 22. Oct 2019, at 07:26, Martin Husemann wrote:
>
> The current state silently breaks existing valid setups ("valid" of course
> in my view, as I personally ran into one that I created myself).
It breaks chrooted services,
On Tue, Oct 22, 2019 at 06:37:44AM +0700, Robert Elz wrote:
> Date:Mon, 21 Oct 2019 21:20:25 +0200
> From:Joerg Sonnenberger
> Message-ID: <20191021192025.ga33...@bec.de>
>
> | That said, I don't really see a point in
> | allowing one form of arbitrary file
Date:Mon, 21 Oct 2019 21:20:25 +0200
From:Joerg Sonnenberger
Message-ID: <20191021192025.ga33...@bec.de>
| That said, I don't really see a point in
| allowing one form of arbitrary file replacement and not another.
If we're thinking of it purely as protection
On Mon, Oct 21, 2019 at 05:34:44PM -, Christos Zoulas wrote:
> In article <20191021163005.ga4...@bec.de>,
> Joerg Sonnenberger wrote:
> >On Mon, Oct 21, 2019 at 06:29:18AM -0700, Hisashi T Fujinaka wrote:
> >> On Mon, 21 Oct 2019, Martin Husemann wrote:
> >>
> >> > On Mon, Oct 21, 2019 at
In article <20191021163005.ga4...@bec.de>,
Joerg Sonnenberger wrote:
>On Mon, Oct 21, 2019 at 06:29:18AM -0700, Hisashi T Fujinaka wrote:
>> On Mon, 21 Oct 2019, Martin Husemann wrote:
>>
>> > On Mon, Oct 21, 2019 at 11:54:44AM +0200, J. Hannken-Illjes wrote:
>> > > Somewhere between Netbsd-8
On 21.10.2019 18:30, Joerg Sonnenberger wrote:
> On Mon, Oct 21, 2019 at 06:29:18AM -0700, Hisashi T Fujinaka wrote:
>> On Mon, 21 Oct 2019, Martin Husemann wrote:
>>
>>> On Mon, Oct 21, 2019 at 11:54:44AM +0200, J. Hannken-Illjes wrote:
Somewhere between Netbsd-8 and NetBSD-9 "tar" changed
On Mon, Oct 21, 2019 at 06:29:18AM -0700, Hisashi T Fujinaka wrote:
> On Mon, 21 Oct 2019, Martin Husemann wrote:
>
> > On Mon, Oct 21, 2019 at 11:54:44AM +0200, J. Hannken-Illjes wrote:
> > > Somewhere between Netbsd-8 and NetBSD-9 "tar" changed its behaviour
> > > when it has to extract a
On Mon, 21 Oct 2019, Martin Husemann wrote:
On Mon, Oct 21, 2019 at 11:54:44AM +0200, J. Hannken-Illjes wrote:
Somewhere between Netbsd-8 and NetBSD-9 "tar" changed its behaviour
when it has to extract a directory and the path exists as a symlink.
I still believe it should be fixed, but J?rg
On Mon, Oct 21, 2019 at 11:54:44AM +0200, J. Hannken-Illjes wrote:
> Somewhere between Netbsd-8 and NetBSD-9 "tar" changed its behaviour
> when it has to extract a directory and the path exists as a symlink.
I still believe it should be fixed, but Jörg disagrees. You need to use -P
now. See PR
Somewhere between Netbsd-8 and NetBSD-9 "tar" changed its behaviour
when it has to extract a directory and the path exists as a symlink.
The attached script on -8 gives:
NetBSD 8.0_STABLE
== Initial:
total 8
drwxr-xr-x 2 hannken staff 512 Oct 21 11:47 realtarget
drwxr-xr-x 2 hannken staff
28 matches
Mail list logo
