vs will respond at the end of the week, he is out at the moment.
Thanks for patch Charles,
Hans
Vladimir,
This patch fixes the issue.
Thanks,
Charles
On Tue, 2005-08-23 at 16:06 +0400, Vladimir V. Saveliev wrote:
> Hello
>
> Charles P. Wright wrote:
> > Vladimir,
> >
> > We actually came across this while working on Unionfs in the kernel,
> > which uses lseek to inquire about directory p
Hello
Charles P. Wright wrote:
> Vladimir,
>
> We actually came across this while working on Unionfs in the kernel,
> which uses lseek to inquire about directory positions and then resume
> directory reading operations (much like nfsd does).
>
Ok, please try whether the attached patch makes rei
Vladimir,
We actually came across this while working on Unionfs in the kernel,
which uses lseek to inquire about directory positions and then resume
directory reading operations (much like nfsd does).
I've attached a user space program that demonstrates the behavior.
The relevant strace entries
Hello
Charles P. Wright wrote:
> Hello,
>
> I've noticed that Reiser4's behavior deviates from other file systems
> when seeking with directories. After reading a directory, if you run
> vfs_lseek(dir, 0, SEEK_CUR), then -ENOENT is returned. This means that
> you can't pass the identifier back
Hello,
I've noticed that Reiser4's behavior deviates from other file systems
when seeking with directories. After reading a directory, if you run
vfs_lseek(dir, 0, SEEK_CUR), then -ENOENT is returned. This means that
you can't pass the identifier back to vfs_lseek with SEEK_SET.
Charles
