gwes wrote:
>
>
> On 02/08/19 15:35, Jeremie Courreges-Anglas wrote:
> >
> > I think it's fair to give the user a chance to understand why
> > scan_ffs(8) won't help in this case.
> >
> > ok?
> >
> >
> > --- scan_ffs.8.~1.16.~ Mon Mar 24 00:28:46 2008
> > +++ scan_ffs.8 Fri Feb 8 21:31:10 2019
> > @@ -136,6 +136,7 @@ you out of a jam when they happen.
> > .Sh SEE ALSO
> > .Xr disklabel 8
> > .Sh BUGS
> > -It is not perfect, and could do a lot more things with date/time
> > information
> > +It is not perfect, does not support FFS2 filesystems,
> > +and could do a lot more things with date/time information
> > in the superblocks it finds, but this program has saved more than one
> > butt,
> > more than once.
> >
> Scan_ffs checks for the the magic number of the superblock.
>
>
> --- scan_ffs.c 23 Nov 2015 19:19:30 -0000 1.21
> +++ scan_ffs.c 9 Feb 2019 02:13:48 -0000
> @@ -67,7 +67,8 @@ ufsscan(int fd, daddr_t beg, daddr_t end
>
> for (n = 0; n < (SBSIZE * SBCOUNT); n += 512){
> sb = (struct fs*)(&buf[n]);
> - if (sb->fs_magic == FS_MAGIC) {
> + if (sb->fs_magic == FS_UFS1_MAGIC ||
> + sb->fs_magic == FS_UFS2_MAGIC) {
> if (flags & FLAG_VERBOSE)
> printf("block %lld id %x,%x
> size %d\n",
> (long long)(blk + (n/512)),
> sb->fs_magic == FS_UFS2_MAGIC) {
> fixes it.
Did you test this? The superblock has a different offset in UFS2.
