• S
    hfsplus: fix longname handling · 89ac9b4d
    Sougata Santra 提交于
    Longname is not correctly handled by hfsplus driver.  If an attempt to
    create a longname(>255) file/directory is made, it succeeds by creating a
    file/directory with HFSPLUS_MAX_STRLEN and incorrect catalog key.  Thus
    leaving the volume in an inconsistent state.  This patch fixes this issue.
    
    Although lookup is always called first to create a negative entry, so just
    doing a check in lookup would probably fix this issue.  I choose to
    propagate error to other iops as well.
    
    Please NOTE: I have factored out hfsplus_cat_build_key_with_cnid from
    hfsplus_cat_build_key, to avoid unncessary branching.
    
    Thanks a lot.
    
      TEST:
      ------
      dir="TEST_DIR"
      cdir=`pwd`
      name255="_123456789_123456789_123456789_123456789_123456789_123456789\
      _123456789_123456789_123456789_123456789_123456789_123456789_123456789\
      _123456789_123456789_123456789_123456789_123456789_123456789_123456789\
      _123456789_123456789_123456789_123456789_123456789_1234"
      name256="${name255}5"
    
      mkdir $dir
      cd $dir
      touch $name255
      rm -f $name255
      touch $name256
      ls -la
      cd $cdir
      rm -rf $dir
    
      RESULT:
      -------
      [sougata@ultrabook tmp]$ cdir=`pwd`
      [sougata@ultrabook tmp]$
      name255="_123456789_123456789_123456789_123456789_123456789_123456789\
       > _123456789_123456789_123456789_123456789_123456789_123456789_123456789\
       > _123456789_123456789_123456789_123456789_123456789_123456789_123456789\
       > _123456789_123456789_123456789_123456789_123456789_1234"
      [sougata@ultrabook tmp]$ name256="${name255}5"
      [sougata@ultrabook tmp]$
      [sougata@ultrabook tmp]$ mkdir $dir
      [sougata@ultrabook tmp]$ cd $dir
      [sougata@ultrabook TEST_DIR]$ touch $name255
      [sougata@ultrabook TEST_DIR]$ rm -f $name255
      [sougata@ultrabook TEST_DIR]$ touch $name256
      [sougata@ultrabook TEST_DIR]$ ls -la
      ls: cannot access
      _123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_1234:
      No such file or directory
      total 0
      drwxrwxr-x 1 sougata sougata 3 Feb 20 19:56 .
      drwxrwxrwx 1 root    root    6 Feb 20 19:56 ..
      -????????? ? ?       ?       ?            ?
      _123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_1234
      [sougata@ultrabook TEST_DIR]$ cd $cdir
      [sougata@ultrabook tmp]$ rm -rf $dir
      rm: cannot remove `TEST_DIR': Directory not empty
    
    -ENAMETOOLONG returned from hfsplus_asc2uni was not propaged to iops.
    This allowed hfsplus to create files/directories with HFSPLUS_MAX_STRLEN
    and incorrect keys, leaving the FS in an inconsistent state.  This patch
    fixes this issue.
    Signed-off-by: NSougata Santra <sougata@tuxera.com>
    Reviewed-by: NChristoph Hellwig <hch@lst.de>
    Cc: Vyacheslav Dubeyko <slava@dubeyko.com>
    Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
    89ac9b4d
hfsplus_fs.h 16.1 KB