Mystery files, "not a directory"

smiler_jerg · 01-24-2009, 06:28 AM

Interesting and tricky problem. I downloaded the source of Pidgin plugin, which I attempted to install. The configure script made some files for this type:

Code:

./conf18760.dir/conf18760.file

There's a lot of these, each with different numbers. The conf*.file lists as a symbolic link, but it's broken (displays as white text on red background).

Every program I try to use on these files complains "Not a directory". I've tried stat, rm, unlink, ls and mv; they all say the same thing: "Not a directory". i.e.:

Code:

bash-3.2$ stat conf18760.file 
  File: stat: cannot read symbolic link `conf18760.file': Not a directory

  Size: 14              Blocks: 1          IO Block: 4096   symbolic link
Device: 21h/33d Inode: 6387        Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (43095/  awm106)   Gid: (   70/    elug)
Access: 2009-01-24 12:21:21.174539300 +0000
Modify: 2009-01-24 11:09:02.116217000 +0000
Change: 2009-01-24 11:09:02.116258400 +0000
bash-3.2$ rm conf18760.file 
rm: cannot remove `conf18760.file': Not a directory

It seems to me like the file isn't really a symbolic link. It's like it's empty. Everything that treats it as a symbolic link fails.

Is there a way to transform this 'symbolic link' into a plain file, so I can delete it? All I'm trying to do is remove this directory tree.

Other random bits of possibly helpful info:

This is in my home directory at university, mounted from a samba server
The system is RHEL5
I don't know what the fileserver runs. Our department uses Solaris, Linux and Windows for servers, but I don't know what this server runs.

{BBI}Nexus{BBI} · 01-24-2009, 06:35 AM

Have you tried deleting using the -f (force) switch?

druuna · 01-24-2009, 07:20 AM

Hi,

What happens if you try to find the original file using find and the inode given?

find -inum 6387

If at all possible try this as root (could be a problem, this being a university box).

smiler_jerg · 01-24-2009, 07:41 AM

Quote:

Originally Posted by {BBI}Nexus{BBI}

Have you tried deleting using the -f (force) switch?

The first thing I did was 'rm -rf ./*' at the top of this directory tree. It deleted everything but these files. I've just tried rm -rf on this file, and I got exactly the same error.

Quote:

Originally Posted by druuna

What happens if you try to find the original file using find and the inode given?

find -inum 6387

I expected this to return nothing, as all the other files it could've pointed to have been deleted. In fact, it returned the symlink itself: conf18760.file. Could '6387' be the inode of the symlink, rather than the file it points to? Otherwise, could this be a recursive symlink?

Thanks for both of your suggestions =)

druuna · 01-24-2009, 08:30 AM

Hi,

6387 is the inode of the linked file, the original should have another inode. Example:

Code:

$ touch real.file.A
$ ln -s real.file.A linked.to.real.file.A

$ stat real.file.A 
  File: `real.file.A'
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 803h/2051d      Inode: 2002881     Links: 1
Access: (0640/-rw-r-----)  Uid: (  500/  druuna)   Gid: (  500/internet)
Access: 2009-01-24 15:22:04.000000000 +0100
Modify: 2009-01-24 15:22:04.000000000 +0100
Change: 2009-01-24 15:22:04.000000000 +0100

$ stat linked.to.real.file.A 
  File: `linked.to.real.file.A' -> `real.file.A'
  Size: 11              Blocks: 0          IO Block: 4096   symbolic link
Device: 803h/2051d      Inode: 2002892     Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (  500/  druuna)   Gid: (  500/internet)
Access: 2009-01-24 15:22:38.000000000 +0100
Modify: 2009-01-24 15:22:26.000000000 +0100
Change: 2009-01-24 15:22:26.000000000 +0100

Maybe it is a recursive link, but that is something I cannot reproduce on my box.

smiler_jerg · 01-24-2009, 08:32 AM

Okay, I've managed to delete these files afterall. I think it must have something to do with being mounted via Samba, and changes not propogating to the server.

I logged into a Linux server and 'rm -rf' on the directory tree: it worked. After refreshing the directory on my local machine, the files were gone. Perhaps there's a bug somewhere.

smiler_jerg · 01-24-2009, 08:37 AM

Quote:

Originally Posted by druuna

Code:

$ stat real.file.A 
  File: `real.file.A'
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 803h/2051d      Inode: 2002881     Links: 1

...

$ stat linked.to.real.file.A 
  File: `linked.to.real.file.A' -> `real.file.A'
  Size: 11              Blocks: 0          IO Block: 4096   symbolic link
Device: 803h/2051d      Inode: 2002892     Links: 1

Those numbers are different. They must be the inode-numbers of themselves, otherwise the inode of linked.to.real.file.A would be the same as the inode of real.file.A.

If my understanding is correct, then the inodes would be the same if linked.to.real.file.A was a hardlink. Perhaps this is what you were thinking of?

Anyway, I'm not sure how or why this happened, but at least I've managed to delete the files. I suspect that remounting the Samba share would have had the same result as logging into another machine. Thanks for your help though!