Re: bin/56300: gpt useless on gpt labels extending beyond disk size (also affects sysinst)

[jnemeth%CornerstoneService.ca@localhost (John Nemeth)]

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

From: jnemeth%CornerstoneService.ca@localhost (John Nemeth)
To: gnats-bugs%netbsd.org@localhost, jnemeth%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost, kardel%netbsd.org@localhost
Cc: 
Subject: Re: bin/56300: gpt useless on gpt labels extending beyond disk size (also affects sysinst)
Date: Wed, 23 Aug 2023 14:54:36 -0700

 On Aug 6, 14:20, David Brownlee wrote:
 } The following reply was made to PR bin/56300; it has been noted by GNATS.
 } 
 } From: David Brownlee <abs%absd.org@localhost>
 } To: gnats-bugs%netbsd.org@localhost
 } Subject: Re: bin/56300: gpt useless on gpt labels extending beyond disk size
 }  (also affects sysinst)
 } Date: Sun, 6 Aug 2023 15:15:05 +0100
 } 
 }  Just hit this when trying to adjust some gpt-in-ccd settings
 }  
 }  Also - easy case to reproduce (without the 'gpt add' step it does not
 }  trigger)
 }  
 }  dd if=/dev/zero bs=1m count=10 > test.img
 }  gpt create test.img
 }  gpt add -t ffs test.img
 }  dd if=test.img of=smaller.img bs=1m count=9
 }  gpt destroy smaller.img
 }  
 }  One thought, there could be some kind of force option to bypass the size
 }  check - possibly by truncating or ignoring oversized entries, which could
 }  be useful for recovering damaged disk images
 
      The problem is that gpt(8) looks like a first year comp-sci
 assignment in linked list manipulation.  The program is all about
 manipulating the list, where the nodes just happen to represent
 disk objects.  It's not very good at handling situations where the
 linked list could get "corrupted".
 
      I've been thinking about ideas for a new data structure.  My
 first idea involved using bitmasks, but I realized that with the
 size of modern disks that was a no go.  I'm open to ideas.
 
 }-- End of excerpt from David Brownlee