sysutils/gpart: deprecated port, anyone interested?

[Matthias Andree]

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'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.

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.

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.

-- 
Matthias Andree
ports committer