Date: Thu, 17 Mar 2011 10:33:38 +0100 From: Matthias Andree <mandree@FreeBSD.org> To: freebsd-ports@FreeBSD.org Cc: Rainer Hurling <rhurlin@gwdg.de> Subject: Re: sysutils/gpart: deprecated port, anyone interested? Message-ID: <4D81D572.20800@FreeBSD.org> In-Reply-To: <4D81AEF3.3040507@gwdg.de> References: <20110316172011.GL51701@eggman.experts-exchange.com> <20110316173613.GO51701@eggman.experts-exchange.com> <1300298080.1474.22.camel@xenon> <4D8108C1.5070006@gwdg.de> <20110317000925.GA59157@apollo.emma.line.org> <4D81AEF3.3040507@gwdg.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D81D572.20800>