Hello,
This is about the third time I've seen this error on recent kernels:
Sometimes my directories, say dir/subdir, become dir//subdir. This
confuses many tools and I've even experienced some 'D' state processes trying
to access such a directory. My most recent problem is that even though 'ls -
l' shows dir/subdir ... 'rm -r' thinks it's dir//subdir and refuses to remove
it. Confusingly, however, 'mv' works and I can move the directory around.
Also cd'ing into the directory is fine too.
$ ls -l
total 1
drwxr-xr-x 3 jesse users 72 Sep 10 14:47 datatable-backup
$ cd datatable-backup; ls -l
total 1
drwxr-xr-x 2 jesse users 256 Sep 10 15:10 CVS
$ rm -r datatable-backup/
rm: cannot remove directory `datatable-backup//CVS': Directory not empty
I've attached the strace file
-Jesse
In article <[email protected]> you wrote:
> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/qt/3/lib/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/qt/3/lib/i686/mmx", 0xbfffe8c0) = -1 ENOENT (No such file or directory)
> open("/usr/qt/3/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/qt/3/lib/i686", 0xbfffe8c0) = -1 ENOENT (No such file or directory)
> open("/usr/qt/3/lib/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/qt/3/lib/mmx", 0xbfffe8c0) = -1 ENOENT (No such file or directory)
> open("/usr/qt/3/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/qt/3/lib", {st_mode=S_IFDIR|0755, st_size=504, ...}) = 0
> open("/usr/kde/3.1/lib/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/kde/3.1/lib/i686/mmx", 0xbfffe8c0) = -1 ENOENT (No such file or directory)
> open("/usr/kde/3.1/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/kde/3.1/lib/i686", 0xbfffe8c0) = -1 ENOENT (No such file or directory)
> open("/usr/kde/3.1/lib/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/kde/3.1/lib/mmx", 0xbfffe8c0) = -1 ENOENT (No such file or directory)
> open("/usr/kde/3.1/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/kde/3.1/lib", {st_mode=S_IFDIR|0755, st_size=35768, ...}) = 0
what kind of system installation do you have, is this intentional? Some kind
of LD_PRELOAD or other wrappers?
> unlink("CVS") = -1 EISDIR (Is a directory)
> chdir("CVS") = 0
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> getdents64(4, /* 0 entries */, 131072) = 0
> chdir("..") = 0
> rmdir("CVS") = -1 ENOTEMPTY (Directory not empty)
interesting... do you get the same empty dir (no . and ..) with ls?
Greetings
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
Hello,
[snip]
...
>> stat64("/usr/kde/3.1/lib/mmx", 0xbfffe8c0) = -1 ENOENT (No such file or directory)
>> open("/usr/kde/3.1/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
>> stat64("/usr/kde/3.1/lib", {st_mode=S_IFDIR|0755, st_size=35768, ...}) = 0
>what kind of system installation do you have, is this intentional? Some kind
>of LD_PRELOAD or other wrappers?
Yeah, I have a LD_LIBRARY_PATH set for development ... etc. etc.
>> unlink("CVS") = -1 EISDIR (Is a directory)
>> chdir("CVS") = 0
>> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
>> getdents64(4, /* 0 entries */, 131072) = 0
>> chdir("..") = 0
>> rmdir("CVS") = -1 ENOTEMPTY (Directory not empty)
>interesting... do you get the same empty dir (no . and ..) with ls?
Yikes!!! -- hadn't noticed (CVS directory is bad for some reason)
$ cd datatable-backup/CVS
$ ls -la
total 0 <-- not good . and .. are not there
whoa ... where did my parent go :(
>Greetings
>Bernd
-Jesse
Hello!
On Thu, Sep 11, 2003 at 09:44:09PM -0500, Jesse Yurkovich wrote:
> >interesting... do you get the same empty dir (no . and ..) with ls?
> Yikes!!! -- hadn't noticed (CVS directory is bad for some reason)
> $ cd datatable-backup/CVS
> $ ls -la
> total 0 <-- not good . and .. are not there
> whoa ... where did my parent go :(
So perhaps it is good idea to run reiserfsck (pick recent reiserfsprogs from ftp.namesys.com)
The reason for this is unknown, though.
Bye,
Oleg