Re: drive names and UUIDs, was Re: Intresting dd fsck grub uuid fstab action
- Date: Sun, 4 Jun 2017 08:31:49 +0900
- From: Joel Rees <joel.rees@xxxxxxxxx>
- Subject: Re: drive names and UUIDs, was Re: Intresting dd fsck grub uuid fstab action
(Google or something is screwing up the threading. My apologies if I
mess it up further.)
On Sun, Jun 4, 2017 at 7:30 AM, Fungi4All <fungilife@xxxxxxxxxxxxxx> wrote:
>> From: deblis@xxxxxxxxxxxxxxxxx
>>> Ι was waiting to see if anyone else found something like this significant
>> and willing to contribute some wisdom
>> No wisdom here, I'm afraid.
> just evolution of the unix-dna
It would definitely be evolution. And it would be something that should be
relegated to an explicitly specified option (maybe like character
encoding stuff), if at all.
And it would be orders of magnitude more complex than what dd now
does. That's part of the reason we have (g)parted and other similar
tools. (And, if you are using LVM, LVM has its own tools.)
>>> Also, I believe that when dd is used to copy something from disk to disk
>>> it should provide an option of whether to
>>> produce a new uuid or retain the original (backup, not a concurrent
>> Here you're asking for the impossible. dd is blind to what it's
>> copying at that level. It can fiddle with something it calls "records"
>> (which stinks of IBM FB↔VB conversion) and that's about it.
> I actually like dd the more I learn about it but what I was suggesting was
> to have
> an option to change the uuid to a new random one after it is done copying.
If at all, an option, but it really is out of dd's scope. dd is not parted.
> I understand (think) that dd does not even care about the format of the fs
> it copies
> or that of what it copies to, just blocks of space, where to start and where
> to finish.
> So if a 10gb NTFS partition is copied to a 20gb EXT4 partition, the target
> will be an
> ntfs 20gb partition.
No, the target will, depending on what you specify, be a 10gb file in
the ext4 partition or a 10gb NTFS partition (overwriting the ext4 file
system completely) and a 10gb gap of unused disk space that the MBR
says goes with the partition which is formatted as a 10gb NTFS
partition, but the NTFS partition really doesn't know anything about
(unless you tell it about it afterwards by expanding the partition
using NTFS tools.)
> So I suspect it does formatting in there too,
dd is not parted, nor is it an NTFS partition editor.
> otherwise the
> partition would have been left half ntfs half ext4.
The MBR partition is left half used by the NTFS file system and half
unused. The unused part may have some useless bits of ext4 left
behind, but it has nothing like a file system in it.
> The kernel I assume as soon as dd is done picks up the new set of uuids and
> updates the table. So if dd does not do it it leaves the system in a mesh.
Not that I am aware. Not unless you tell the kernel to do so.
One of these days I'll get someone to pay me
to design a language that combines the best of Forth and C.
Then I'll be able to leap wide instruction sets with a single #ifdef,
run faster than a speeding infinite loop with a #define,
and stop all integer size bugs with a bare cast.
More of my delusions: