On 2015-12-05 07:01, Hugo Mills wrote:
On Sat, Dec 05, 2015 at 04:28:24AM +0100, Christoph Anton Mitterer wrote:
On Fri, 2015-12-04 at 13:07 +, Hugo Mills wrote:
I don't think it'll cause problems.
Is there any guaranteed behaviour when btrfs encounters two filesystems
(i.e. not talking ab
Christoph Anton Mitterer posted on Wed, 09 Dec 2015 06:07:38 +0100 as
excerpted:
> Well as I've said, getting that in via USB may be only one way.
> We're already so far that GNOME&Co. automount devices when plugged...
Ugh. ... And many know that's the sort of thing that made MS so much of
a se
On Sun, 2015-12-06 at 04:06 +, Duncan wrote:
> There's actually a number of USB-based hardware and software vulns
> out
> there, from the under $10 common-component-capacitor-based charge-
> and-zap
> (charges off the 5V USB line, zaps the port with several hundred
> volts
> reverse-polarity, i
Christoph Anton Mitterer posted on Sun, 06 Dec 2015 02:51:20 +0100 as
excerpted:
> You have things like ATMs, which are physically usually quite well
> secured, but which do have rather easily accessible maintenance ports.
> All of us have seen such embedded devices rebooting themselves, where
> y
On Sat, 2015-12-05 at 13:19 +, Duncan wrote:
> The problem with btrfs is that because (unlike traditional
> filesystems)
> it's multi-device, it needs some way to identify what devices belong
> to a
> particular filesystem.
Sure, but that applies to lvm, or MD as well... and I wouldn't know o
On Sat, 2015-12-05 at 12:01 +, Hugo Mills wrote:
> On Sat, Dec 05, 2015 at 04:28:24AM +0100, Christoph Anton Mitterer
> wrote:
> > On Fri, 2015-12-04 at 13:07 +, Hugo Mills wrote:
> > > I don't think it'll cause problems.
> > Is there any guaranteed behaviour when btrfs encounters two
> > f
Christoph Anton Mitterer posted on Sat, 05 Dec 2015 04:28:24 +0100 as
excerpted:
> On Fri, 2015-12-04 at 13:07 +, Hugo Mills wrote:
>> I don't think it'll cause problems.
> Is there any guaranteed behaviour when btrfs encounters two filesystems
> (i.e. not talking about the subvols now) with t
On Sat, Dec 05, 2015 at 04:28:24AM +0100, Christoph Anton Mitterer wrote:
> On Fri, 2015-12-04 at 13:07 +, Hugo Mills wrote:
> > I don't think it'll cause problems.
> Is there any guaranteed behaviour when btrfs encounters two filesystems
> (i.e. not talking about the subvols now) with the same
Thinking a bit more I that, I came to the conclusion that it's actually
security relevant that btrfs deals gracefully with filesystems having the same
UUID:
Getting to know someone else's filesystem's UUID may be more easily possible
than one may think.
It's usually not considered secret and fo
On Fri, 2015-12-04 at 13:07 +, Hugo Mills wrote:
> I don't think it'll cause problems.
Is there any guaranteed behaviour when btrfs encounters two filesystems
(i.e. not talking about the subvols now) with the same UUID?
Given that it's long standing behaviour that people could clone
filesystem
On Fri, Dec 04, 2015 at 01:05:28PM +0100, S.J wrote:
> Hello
>
> As we know, two file systems with the same UUID (like reported by eg.
> "blkid") are problematic, especially if both are mounted at the same time it
> leads to data corruption. So, copying a BTRFS partition with eg. dd to
> anothe
Hello
As we know, two file systems with the same UUID (like reported by eg. "blkid")
are problematic, especially if both are mounted at the same time it leads to
data corruption. So, copying a BTRFS partition with eg. dd to another and use
it immediately is bad. To prevent this, "btrfstune -u /
12 matches
Mail list logo