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.

Reply via email to