On Fri, Dec 18, 2020 at 11:44 AM Filipe Manana wrote:
>
> On Fri, Dec 18, 2020 at 7:25 AM Massimo B. wrote:
> >
> > On Mon, 2020-12-14 at 09:46 +, Filipe Manana wrote:
> >
> > > clone mb/Documents.AZ/0.SYNC/pdf -
> > > source=mb/Documents.AZ/0.SYNC/pdf
> > > > source offset=20705280
On Fri, Dec 18, 2020 at 7:25 AM Massimo B. wrote:
>
> On Mon, 2020-12-14 at 09:46 +, Filipe Manana wrote:
>
> > clone mb/Documents.AZ/0.SYNC/pdf - source=mb/Documents.AZ/0.SYNC/pdf
> > > source offset=20705280 offset=20709376 length=4096
> > > clone mb/Documents.AZ/0.SYNC/pdf -
>
On Mon, 2020-12-14 at 09:46 +, Filipe Manana wrote:
> clone mb/Documents.AZ/0.SYNC/pdf - source=mb/Documents.AZ/0.SYNC/pdf
> > source offset=20705280 offset=20709376 length=4096
> > clone mb/Documents.AZ/0.SYNC/pdf - source=mb/Documents.AZ/0.SYNC/pdf
> > source offset=20713472
07.06.2018 05:50, Christoph Anton Mitterer пишет:
> Hey.
>
> Just wondered about the following:
>
> When I have a btrfs which acts as a master and from which I make copies
> of snapshots on it via send/receive (with using -p at send) to other
> btrfs which acts as copies like this:
> master +-->
Hey.
Just wondered about the following:
When I have a btrfs which acts as a master and from which I make copies
of snapshots on it via send/receive (with using -p at send) to other
btrfs which acts as copies like this:
master +--> copy1
+--> copy2
\--> copy3
and if now e.g. the dev
Hi guys,
It seems that btrfs v4.12.1 allows:
(1) btrfs send -p
but disallows
(2) btrfs send -p
Code-wise it assumes that is always found at optind == 1. I was
about to patch this but I'm not sure which way we'd like to go with this:
Actually only allow (1) an
