On Tue, Mar 17, 2015 at 03:33:14PM -0500, Eric Sandeen wrote:
> process_dir2_data() has special . and .. processing; it is able
> to correct these inodes, so there is no reason to clear them.
>
> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
> ---
> repair/dir2.c | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/repair/dir2.c b/repair/dir2.c
> index 9e6c67d..3acf71c 100644
> --- a/repair/dir2.c
> +++ b/repair/dir2.c
> @@ -1331,6 +1331,18 @@ _("entry at block %u offset %" PRIdPTR " in directory inode %" PRIu64
> dep->namelen = 1;
> clearino = 1;
> }
> +
> + /*
> + * We have a special dot & dotdot fixer-upper below which can
> + * sort out the proper inode number, so don't clear it.
> + */
> + if ((dep->namelen == 1 && dep->name[0] == '.') ||
> + (dep->namelen == 2 &&
> + dep->name[0] == '.' && dep->name[1] == '.')) {
> + clearino = 0;
> + clearreason = NULL;
> + }
> +
Whitespace damage on the blank line above.
Seems Ok, but the question I have is what happens if the dot or dotdot
namelen was bogus? The change in behavior here is that we don't trash
the entry, right? If so, are we reliant on something else detecting
absence of either entry later and fixing it up?
Brian
> /*
> * If needed to clear the inode number, do it now.
> */
> --
> 1.7.1
>
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
