git: sbin/hammer: Partly revert 8b640662 in 2014

Tomohiro Kusumi tkusumi at crater.dragonflybsd.org
Sat Oct 8 18:29:56 PDT 2016


commit 578f0d566f1c8316df3f69dfc80dd00d92cbdba4
Author: Tomohiro Kusumi <kusumi.tomohiro at gmail.com>
Date:   Thu Sep 22 07:04:18 2016 +0900

    sbin/hammer: Partly revert 8b640662 in 2014
    
    I guess it makes sense that 8b640662 silently ignores trailing / and
    do destructive operations to a filesystem, since there isn't really
    anything one can do by specifying a root inode (directory) of a PFS,
    but it shouldn't silently modify (not ignore) the user input.
    
    A command like pfs-status uses that input after calling getpfs(),
    so the program should not silently modify the string and print it
    as if that was the user input, because it's not. It should also avoid
    modifying argv[i] even if it's technically possible (make it shorter).
    
    It's also better to do it based on lstat(2) result than unconditionally
    checking a trailing / based on assumption that a symlink that ends
    with / is a directory (which is right if it actually exists).
    
    The only case behaves differently from 8b640662 is when there is a
    slave PFS that hasn't been synced with a master PFS yet after created.
    In this case it fails to run commands using path arg with trailing /,
    because lstat(2) mentioned above in scanpfsid() fails due to lack of
    the root inode. This occurs by design of HAMMER, but not a tool issue.
    
    Above won't be a problem either because the scenario mentioned in
    8b640662 is mostly about auto completion by a shell, while in this
    case the shell just recognizes it as a broken link. The tool doesn't
    need to assist everything that users would potentially do based on
    assumption that may be right or wrong.
    Also see http://lists.dragonflybsd.org/pipermail/users/2015-April/228012.html
    
    -----
    Actually I even suspect reports by users and 8b640662 were wrong
    in the first place, because one would still get the same PFS id from
    both "symlink" and "symlink/" when "symlink" is a symlink to PFS.
    "symlink" can extract the PFS id directly from "@@.." format, but
    "symlink/" eventually results the same via hammer_pfs_autodetect().
    In fact I could pfs-upgrade/pfs-downgrade by reverting whole 8b640662.
    
    Having said that, it still needs to strip trailing / on pfs-destroy
    otherwise it won't be able to remove a symlink to PFS after it gets
    destroyed.

Summary of changes:
 sbin/hammer/cmd_mirror.c |  4 +--
 sbin/hammer/cmd_pfs.c    | 78 +++++++++++++++++++++++++++++++-----------------
 sbin/hammer/hammer.h     |  2 +-
 3 files changed, 54 insertions(+), 30 deletions(-)

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/578f0d566f1c8316df3f69dfc80dd00d92cbdba4


-- 
DragonFly BSD source repository


More information about the Commits mailing list