Actually lseek looks at the file size -- that's all.
> readdir requires a lock on inode in question for damn good reasons.
No problem. There's only one inode it has to lock.
> > 2. The filp has two dentries.
> > Most operations use the usual one, but readdir uses the other, and
> > lseek knows to operate on both if they are different.
> >
> > Has no limitation w.r.t. symbolic links, but uses a bit more space in
> > filps.
> Ditto. Locking is not going to be fun that way.
Can you describe the problem?
Remember that this happens in filps only -- non-filp operations like
mkdir, rename etc. don't see it.
This is what I think happens:
sys_open
-> lookup_dentry
-> lookup_dentry(dentry, "default")
-> store 1st in filp->dentry_for_readdir
-> store 2nd in filp->dentry
sys_close
... nearly as now but an additional release() call if
dentry != dentry_for_readdir.
But I must admit, the role of filp->f_op is not too clear here.
Perhaps f_op_for_readdir is required too.
> Ahem... And what about ->create()/->unlink()/.... stuff? What about
> renaming an open file?
Ahem, oh _that_ stuff ;-)
Now I definitely prefer proposal 2: filp has two dentries.
If there are no locking problems.
It's done the filp layer, created by open() -- renaming, mkdir,
creat and so on don't see this stuff.
sys_rename() would simply rename the directory and everything works.
Your wonderful code handles directory renames just fine.
sys_unlink() is icky -- but ok from the kernel's point of view. It
would return EISDIR since you've given it the name of a directory.
Arguably it should recursively delete the directory tree -- to give
the appearance of deleting a structured file. Arguably it shouldn't.
create() -- what problem?
Another happy thought from...
-- Jamie
-
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/