Building m4-1.14.15 creates directories that can't be deleted.

[scottmc]

Steps to reproduce: Download m4-1.4.15: ​http://ftp.gnu.org/gnu/m4/m4-1.4.15.tar.gz Unzip and run: ./configure --prefix=/boot/common after configure is done try removing conftest.dir, you might be able to get it into the trash, but then can't remove it from trash. rm -rf won't do it either...

[korli]

Reproduced with hrev40793. Syslog output

bfs: InitCheck:311: Bad data
bfs: inode at 217637 is already deleted!
bfs: InitCheck:311: Bad data
bfs: inode at 217637 is already deleted!
bfs: InitCheck:311: Bad data
bfs: inode at 217637 is already deleted!
bfs: InitCheck:311: Bad data
bfs: inode at 217637 is already deleted!
bfs: InitCheck:311: Bad data
bfs: inode at 217637 is already deleted!
bfs: InitCheck:311: Bad data
bfs: inode at 217637 is already deleted!
bfs: Remove:2487: Bad data
bfs: InitCheck:311: Bad data
bfs: inode at 217637 is already deleted!
bfs: InitCheck:311: Bad data
bfs: inode at 217637 is already deleted!
bfs: InitCheck:311: Bad data
bfs: inode at 217637 is already deleted!
bfs: InitCheck:311: Bad data
bfs: inode at 217637 is already deleted!

[mmadia]

Seems I've filed a similar ticket with the same root issue: #7276. Here's the information from that ticket.

​gettext-0.18.1.1's gettext-tools/configure script can reliably generate BFS issues, through testing "rmdir"

The issue seems to be rmdir ("conftest.dir/./"); Both <dirname>/ and <dirname>/. do not trigger the BFS issues (judging by syslog output).

At one point, Urias mentioned that browser:haiku/trunk/src/system/kernel/fs/vfs.cpp#5807 dir_remove()

To reproduce

wget http://ftp.gnu.org/pub/gnu/gettext/gettext-0.18.1.1.tar.gz
tar xvf gettext-0.18.1.1.tar.gz
cd gettext-0.18.1.1/gettext-tools 
./configure 

gettext-tools/configure snippet

(line 38205)

    { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether rmdir works" >&5
$as_echo_n "checking whether rmdir works... " >&6; }
if test "${gl_cv_func_rmdir_works+set}" = set; then :
  $as_echo_n "(cached) " >&6
else
  mkdir conftest.dir
     touch conftest.file
     if test "$cross_compiling" = yes; then :
  gl_cv_func_rmdir_works="guessing no"
else
  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h.  */
#include <stdio.h>
           #include <errno.h>
           #include <unistd.h>

int
main ()
{
return !rmdir ("conftest.file/") || errno != ENOTDIR
       || !rmdir ("conftest.dir/./");
  ;
  return 0;
}
_ACEOF
if ac_fn_c_try_run "$LINENO"; then :
  gl_cv_func_rmdir_works=yes
else
  gl_cv_func_rmdir_works=no
fi
rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
  conftest.$ac_objext conftest.beam conftest.$ac_ext
fi

     rm -rf conftest.dir conftest.file
fi

syslog output

KERN: bfs: Remove:1741: No such file or directory
KERN: bfs: Could not find value in index "name"!
KERN: bfs: Update:278: No such file or directory
KERN: bfs: InitCheck:311: Bad data
KERN: bfs: inode at 4728676 is already deleted!
KERN: bfs: InitCheck:311: Bad data
KERN: bfs: KERN: inode at 4728676 is already deleted!
KERN: bfs: Remove:2487: Bad data

checkfs

gettext-0.18.1.1/gettext-tools> checkfs -c /boot
sub (inode = 1574266), has blocks already set
conftest.dir (inode = 4728676), could not be opened
        51521 nodes checked,
        0 blocks not allocated,
        3 blocks already set,
        0 blocks could be freed

        files           42955
        directories     8171
        attributes      213
        attr. dirs      168
        indices         14

[korli]

Committed a fix in hrev40819. Another way would be to disallow removing such a path, as Linux does.

[axeld]

I would not really consider this fixed, as the BFS side should not produce broken directories either. Have you investigated what happens on that end, and care to elaborate?

[scottmc]

It seems to me that hrev40819 did fix it, as I am now able to delete the working directories after building m4 with tracker or from a command line, and the don't get stuck in the trash now either, so this might also take care of #6685.

[korli]

To Axel: No, I didn't investigate on the BFS side. I just guess what happens is this:
if asked to remove "dir/./" in the current directory, VFS asked BFS to remove the "." entry in the directory "dir" vnode.

In fact, BFS could handle this case nicer and return an error. File systems can also expect this case handled upward.

[axeld]

You mean bfs_remove_dir() has been called with "." as name? That would be indeed something the VFS should prevent from happening. Thanks for the explanation!