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
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
