LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - General (https://www.linuxquestions.org/questions/linux-general-1/)
-   -   Mystery files, "not a directory" (https://www.linuxquestions.org/questions/linux-general-1/mystery-files-not-a-directory-699563/)

smiler_jerg 01-24-2009 06:28 AM

Mystery files, "not a directory"
 
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} (Post 3419566)
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 (Post 3419593)
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

Solved (ish)
 
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 (Post 3419663)
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!


All times are GMT -5. The time now is 01:23 PM.