Am 28.11.2016 um 20:53 schrieb Tito:
On 11/28/2016 05:42 PM, Simon Rettberg wrote:
27.11.2016, 20:24 +0200, Denys Vlasenko <vda.li...@googlemail.com>:
However, I still don't understand how do you use them,
apart from seeing them on output.
That's pretty much it. Following the same line of argument, you could
ask why we have this table in fdisk.c that maps the MBR type ids
to their names. They also do nothing except for showing up in the
output.
Plus, in case bb fdisk will get write support for GPT one day, the
table would be even more useful, since you usually just enter the type
code in existing GPT editing tools, instead of the full GUID. The
utility then just maps the short type code back to the long GUID when
writing.
Actually, the type codes of GPT are based on the type ids from MBR,
so for example HPFS/NTFS is 07 for MBR and 0700 for GPT, Linux Swap
is 82 for MBR, 8200 for GPT.
Hi,
one stupid question, could the 2 tables be merged or reused in some way
as they share related values (e.g. 82 and 8200)?
During the last weeks I did some tests on dual MBR and GPT partition
tables, mainly for building bootable USB thumb drives taht have one
partition visible and usable under Windows.
If the drive is less than 2TB and four partitions or less are used, it
is very easy to use dual partition tables. If more partitions are used
or some partitions should only be visible on MBR and others on GPT it
gets tricky: Linux for example expects the protective partition to start
at the second block, no matter how big the protective partition is and
how many partitions follow. If this is the case Linux uses the GPT and
ignores the rest of the MBR. Windows however expects a protective
partition that spans the whole disk, otherwise it will use the MBR. So
if you insert a USB drive with a small protective partition into
Windows, Windows will prompt you to format the (unknown) partition. Only
OS X ignores any MBR partitioning if a GPT is present.
So while theoretically interesting, in practice it does not make sense
to sync partition tables. Use GPT on any linux only system (also makes
sense on BIOS, albeit a bit more work to boot from), use GPT on any
external media. Use GPT on any UEFI system as boot media, and only use
MBR on drives with less than 2TB that should boot windows on BIOS (64
bit windows 7 and up should be possible to boot from GPT on BIOS - I did
not yet test).
Yours,
Mattias
Ciao,
Tito
When you send a patch, add a bit of background why do you need this
change,
and if there were other solutions which at first looked better, but
then proved
non-workable, mention those too.
For example, before I saw your email, I looked at fdisk_gpt.c and
decided to simply delete "Code" column on the output. I take it this
is not a good idea?
Why?
Alright, so as mentioned above, those type codes are almost exclusively
used when humans are dealing with GPT partitions in any way.
Not supporting them in busybox would not mean the end of the world; we
could still do everything by reading (and some day writing) type GUIDs
directly, at the expense of having to look them up manually every time,
unless you can memorize them.
As for removing the column: I saw that the formatting of the output
looks exactly like that of gdisk, so I assumed the original author
of fdisk_gpt.c decided that it would be better to print a dummy
value than not having the column at all.
I can't speak for the rest of the world, but I don't care about that
output format compatibility, so I would be fine with not having that
column instead of printing a misleading dummy value; it might
actually be the more reasonable choice, since it had me confused for
a while before checking the source. A new column showing the GUID
directly would be ok with me. I would change my scripts and add a
lengthy comment, probably.
But showing neither the short code nor the GUID does render the output
somewhat useless, just as if MBR mode would not print the type id.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
--
Mattias Schlenker - Freier IT-Fachredakteur und -autor
redakt...@mattiasschlenker.de
Mattias Schlenker - IT-Consulting, Softwareentwicklung
consult...@mattiasschlenker.de
Address__ August-Bebel-Str. 74 - D-04275 LEIPZIG - GERMANY
Phone: +49 341 39290767 Fax: +49 341 30393578
Mobile: +49 163 6953657 Another mobile: +49 159 03160327
VATIN_________________________________________ DE240998538
Fork me!____________________ https://github.com/mschlenker
Website.__________________ http://www.mattiasschlenker.de/
My books!___________ http://www.arduino-hausautomation.de/
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
