sysutils/gpart: deprecated port, anyone interested?

[Rainer Hurling]

On 17.03.2011 10:33 (UTC+1), Matthias Andree wrote:
> Am 17.03.2011 07:49, schrieb Rainer Hurling:
>> Hey Matthias,
>>
>> thanks for taking this up.
>>
>> Am 17.03.2011 01:09 (UTC+1) schrieb Matthias Andree:
>>> On Wed, Mar 16, 2011 at 08:00:17PM +0100, Rainer Hurling wrote:
>>>
>>>> gpart in sysutils/gpart stands for 'guess partitions'. Its an old, but
>>>> very useful tool for repairing partitions. Unfortunately it does not
>>>> work on amd64.
>>>
>>> I've added two patches to make it work on amd64, bumped the expiration
>>> date and port revision (to 2), but I'm not sure if it can detect all
>>> relevant partition types yet. It detects my BSD UFS partitions, but not
>>> my Windows 7 NTFS partitions, and it would probably also need ZFS
>>> detection.
>>
>> I can confirm that it builds and install on amd64 again.
>
> Sure enough - I'd tested that on my amd64 Tinderbox. :)
>
>> Newer partition types are not known to sysutils/gpart. For me it is a
>> useful tools to repair (older) servers with Win2000 or something like
>> that. In some cases it was the only tool, which was able to reconstruct
>> destroyed partition tables.
>
> Sounds reasonable. Could you test the amd64 version on some of the disks
> and see if it guesses reasonable partition tables, and finds existing
> partitions, too? I don't trust it yet, as there has been quite a bit of
> C integer data type abuse in the source code when, even ten years ago,
> /usr/include/inttypes.h existed... although the source code isn't all bad.

I tried to test gpart on one of my systems. I have at least two issues 
with it:

(1) It seems, that there is a serious problem with ada drives (ahci 
mode). sysutils/gpart is not able to differentiate between my drives 
ada0 and ada1:

/usr/local/sbin/gpart /dev/ada0
/usr/local/sbin/gpart /dev/ada1

On both harddisks I get the same result (of ada0). It would be nice if 
someone could double-check this.

Applying sysutils/gpart on modern terra byte harddrives will take very 
long times per partition. So it is doubtful wether it is reasonable to 
use the tool for such big drives.


(2) The sysutils/gpart manpage is not found with 'man 8 gpart'. Instead 
the systems gpart manpage (for disk partitioning GEOM class) is found.


Perhaps a pkg-message should explain the difference of this port against 
the GEOM classes tool? Or it has even to renamed?


> I've fixed more than one "unsigned long" instance to uint32_t but didn't
> have time yet to look deeper to see, for instance, if all the block
> structures are 2^N (for N typically 9) bytes tall.
>
> An alternative appears to be <http://www.cgsecurity.org/wiki/TestDisk>
> (GPL'd), but I haven't looked closer, but the list of supported file
> systems is longer and comprises newer NTFS and exFAT, but not zfs/zpool
> either.
>
>>>> If someone is willing to update the port: I have an original tarball
>>>> 'gpart-0.1h.tar.gz'. It would need a new home ;-)
>>>
>>> Is that tarball different from what's on sunsite and currently fetched
>>> by the port?
>>
>> I compared it against my old distfile and all seems fine:
>>
>> ls -l old/gpart-0.1h.tar.gz new/gpart-0.1h.tar.gz
>> 52357 15 Feb 19:24:06 2001 old/gpart-0.1h.tar.gz
>> 52357 15 Feb 19:24:06 2001 new/gpart-0.1h.tar.gz
>>
>> SHA256 (old/gpart-0.1h.tar.gz) =
>> b542bceb1a778c719304dadae5dbc2a8bd7f195c06774933e7255b98cfa46ee3
>> SHA256 (new/gpart-0.1h.tar.gz) =
>> b542bceb1a778c719304dadae5dbc2a8bd7f195c06774933e7255b98cfa46ee3
>>
>> The updated port is still marked as deprecated. Do you plan to change
>> this back?
>
> Thanks for the comparison.

I am pleased about your initiative :-)

> What I'd like to see happen for an un-deprecation is a united effort to
> contact the former maintainer about his plans and situation, and else a
> coordination of the changes that other distributors may have added, too,
> so as to create a unified effort.

I am afraid the it will be hard to get a contact. I tried it also some 
years ago.

> Basically we'd need a maintainer for the port and possibly for the
> upstream code, too, but I don't plan to sign up for yet another
> maintainership.
>
> However, I don't have strong feelings about this either way.
>
> Original author Bcc'd.

Thanks again for your work,
Rainer