Here's the situation I'm trying to track down:
Let us use as an example the file /home/jehahn/Mail/drafts/1. it is
served by knfsd. On occassion (since this file an MH draft, it is
frequently deleted and recreated), MH reports it is a directory. Which
it clearly isn't, as it is (in most cases) a text file sitting in
emacs in front of me (that I've already C-x s'ed a couple of times...)
So I think, well is this MH screwing up? No, because running:
file /home/jehahn/Mail/drafts/1 returns:
/home/jehahn/Mail/drafts/1: is a directory (or something close).
So I'm figuring that stat must be indicating that the file is a
directory. I'm going to sit down with the code thoroughly tomorrow
afternoon and try to get a deeper understanding of it. Right now my
suspicion is that somewhere something is returning an nfs_fh with it's
directory inode equal to it's own inode. But that's probably totally
naive. This is why if I have a call chain (or a way of getting one...)
I can start looking at the source.
Unfortunately, strace is of no use to me (as it does nothing with the
nfsd processes), and gdb attaching to the nfs daemons just hangs
blankly.
So if someone could point me in the right direction I'd be much obliged.
Admittedly this will be my first serious bit of kernel hackery besides
prodding and bits on my personal machine.
Thanks a million, and sorry for the long post.
-----------------------------------------------
Justin Hahn <jehahn@raven.bu.edu>
Systems Administrator Boston University SPI Lab
-----------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/