Hello Hans, here is some oddness experienced with reiserfs on a server which runs on reiserfs at least since linux-2.4.0-test10. Please look at this shell listing: plato:~ # cd temp plato:~/temp # cd flow plato:~/temp/flow # ls -1|head -n 7 /dev/initctl /etc/mtab /lib/libc.so.6 /lib/libc.so.6 /proc/25177/statm /usr/bin/killall /usr/bin/top plato:~/temp/flow # ls -1|tail -n 4 mess/13/82100 mess/14/996604 mess/19/865509 mess/4/1546156 plato:~/temp/flow # The directory "~/temp/flow" contains other files with normal names, too (but I cannot disclose that filenames to the public). I just wanted to remove that directory with "rm -rf flow". That screwed up my whole system, because "rm" also removed "/lib/libc.so.6", "/etc/mtab" and so on. The server had linux-2.4.2 running at the time I tried to remove that directory. I now have linux-2.4.6 running there. I think the "offending kernel" (the kernel under which the bug was created) is linux-2.4.2. I had been running an application some weeks ago which created a vast amount of files in the directory. The server has also other applications on it, like a qmail server. It seems, that something has made reiserfs shuffle requests between different applications. My file writer application wanted to create a new file with a given name, and at the same time, some other application maybe requested "/lib/libc.so.6" to be loaden. Now reiserfs created an directory entry with the name "/lib/libc.so.6". This is the only explanation I can think of. What is also a fact, but which I cannot write here in the public, is that if the name of the wrong file (like "/lib/libc.so.6") is longer than the name of the file originally opened to be written, it is capped to that length. If the file to be created is called 0123456789 and the substituted name is /usr/src/linux/arch/i386/boot the resulting name will be /usr/src/l So the question is: Is this bug known to be present in linux-2.4.2 and fixed at least in linux-2.4.6, or is this a new kind of bug? I do not like to unlink my "/lib/libc.so.6" again... this is very painful to restore. Note that I cannot access the contents of those special files because the name of the file contains a slash '/'. But I have found similar files in other directories and it seems that the contents are the contents which were to be written by the file create application. Only the name got wrong. Xu�n.
