Re: bin/60208: 'gpt add' should error if the specified label already exists

["Michael van Elst via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/60208; it has been noted by GNATS.

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/60208: 'gpt add' should error if the specified label already exists
Date: Fri, 24 Apr 2026 05:32:48 -0000 (UTC)

 gnats-admin%NetBSD.org@localhost ("jschauma%netmeister.org@localhost via gnats") writes:
 
 >When creating a new wedge, gpt(8) allows you to specify a label using the
 >'-l' command-line option.
 
 >If the label specified already exists, gpt(8) uses a default label without
 >giving the user any indication that the specified label was not used.
 
 
 gpt(4) writes the label you gave it into the GPT, it doesn't
 silently use a "default label", there isn't any.
 
 gpt(4) then runs "dkctl makewedges" to (re-)create wedges for
 the disk.
 
 The wedge driver must reject duplicate names and falls back
 to the partition UUID and accepts it when unique. So even this
 can fail if you e.g. had cloned a disk image and didn't run
 gpt uuid.
 
 If you resolve the conflict in the GPT, the driver will even
 try to use the label as wedge name, but may fail when the
 partition is already in use.
 
 
 Duplicate partition labels are allowed by the GPT specification,
 but if you use them, you may need to deal with the consequences.
 E.g. Linux will just overwrite partition links so that the
 last one wins.
 
 
 For better feedback it might be interesting to redirect some
 wedge driver messages to the user terminal. The kernel has
 this capability, but it is only used in ancient code parts.
 I'm not sure how that would be accepted.
 
 gpt(4) could also warn you about duplicates within a GPT, I
 don't think it should scan other disks or try to guess your
 intention. After all, the conflict might not exist yet and
 will only be created by attaching another disk after the GPT
 change.