Roland McGrath <[EMAIL PROTECTED]> writes:
> However, I think diskfs should not return EOPNOTSUPP for this case. On
> Unix systems I have tried, trying to execute a device file (that has
> execute bits set) fails with EACCES. That seems like the appropriate error
> for attempting to open a syml
> On Sun, May 12, 2002 at 03:59:23PM -0400, Roland McGrath wrote:
> > That seems like a reasonable deduction. I've made fakeroot treat
> > EOPNOTSUPP like EACCES here.
>
> But we get ENOTDIR because of lookup_error mangling, not EOPNOTSUPP.
Oh, right. I wasn't thinking about file_name_lookup_u
On Sun, May 12, 2002 at 03:59:23PM -0400, Roland McGrath wrote:
> That seems like a reasonable deduction. I've made fakeroot treat
> EOPNOTSUPP like EACCES here.
But we get ENOTDIR because of lookup_error mangling, not EOPNOTSUPP.
> I also made it try zero openmodes if all else
> fails.
Thanks
> The problem is symbolic links. We get ENOTDIR from file_name_lookup_under
> when trying to open a symbolic link to a file with the O_EXEC bit set, and
> we don't catch this in netfs_attempt_fakeroot. I have not verified it, but
> had I to venture a guess I would say this comes from the EOPNOTS
On Sun, May 05, 2002 at 04:27:47PM -0400, Roland McGrath wrote:
> Oh, that EISDIR must be from opening with write permission in
> netfs_attempt_lookup. I made it check for EROFS or EISDIR as it does for
> EACCES. If there are other possible errors for an O_RDWR open that aren't
> possible for a
Roland McGrath <[EMAIL PROTECTED]> writes:
> To make cases like the current state less confusing, perhaps netfs (and
> diskfs) should do something special for an EOPNOTSUPP return from
> *_get_translator in lookup/getroot. It will only come up there if
> S_IPTRANS is set, which the *_validate_st
On Sat, May 11, 2002 at 04:17:25PM -0400, Roland McGrath wrote:
> Oh yeah, the patch:
> + err = netfs_validate_stat (netfs_root_node, 0);
> + if (err)
> +error (6, err, "Cannot stat underlying node");
> +
> + netfs_root_node->nn_stat.st_mode &= ~(S_IPTRANS | S_IATRANS);
> + netfs_root_nod
Oh yeah, the patch:
Index: fakeroot.c
===
RCS file: /cvsroot/hurd/hurd/trans/fakeroot.c,v
retrieving revision 1.6
diff -u -b -p -r1.6 fakeroot.c
--- fakeroot.c 6 May 2002 00:40:14 - 1.6
+++ fakeroot.c 11 May 2002 20:13:1
The intent of fakeroot is to be unaware of translators in the underlying
directory tree. That is, to use the translated nodes transparently; that's
why its lookups don't use O_NOTRANS. If you think about it, that's the
only thing that really makes sense for a translator applied to whole
director
On Sat, May 11, 2002 at 05:12:15AM +0200, Marcus Brinkmann wrote:
> This is indeed what happens, here in more detail:
What I describe here is the error in the passive translator case.
I tried this change:
diff -u -p -r1.6 fakeroot.c
--- fakeroot.c 6 May 2002 00:40:14 - 1.6
+++ fakeroo
On Sat, May 11, 2002 at 01:51:36AM +0200, Marcus Brinkmann wrote:
> Maybe the way netfs_root_node is looked up in the passive translator case is
> screwed? I set a breakpoint at netfs_demuxer, and a "chdir fakeroot-test"
> gave me three fsys_getroot RPC in sequence before it failed with ENOTDIR.
On Sun, May 05, 2002 at 07:07:40PM -0400, Marcus Brinkmann wrote:
> Still no cigar though, as trying to lookup bin/bash in the --chroot
> case says ENOTDIR (and in a debugging session it seemed to be that the
> faked node created by netfs_attempt_lookup didn't have the S_IFDIR flag
> set). This s
On Sun, May 05, 2002 at 04:27:47PM -0400, Roland McGrath wrote:
> Oh, that EISDIR must be from opening with write permission in
> netfs_attempt_lookup. I made it check for EROFS or EISDIR as it does for
> EACCES.
Yeah, that's it. I will also make this change for the O_RDWR case
(you did it onl
Oh, that EISDIR must be from opening with write permission in
netfs_attempt_lookup. I made it check for EROFS or EISDIR as it does for
EACCES. If there are other possible errors for an O_RDWR open that aren't
possible for a O_RDONLY open, we should check for those as well. Or we
could make it j
> Can you think of any specific failure case I could test, or is it just a
> vague feeling?
I can't think of any case reasonable other than the translated underlying
node itself that would hit the new code. Maybe firmlink, but that would
only come up if there was a firmlink to a fakeroot virtu
On Sun, May 05, 2002 at 03:23:39PM -0400, Roland McGrath wrote:
> It's not clear to me what case gets EISDIR and what case hangs.
$ ./settrans --chroot /bin/bash -i -- /bin /hurd/fakeroot
./settrans: cannot chdir to new root: Is a directory
The "cd foo" case is fixed now, it doesn't hang anymor
Roland McGrath <[EMAIL PROTECTED]> writes:
> Probably the right thing to do is unlock the directory node while doing the
> lookups.
This is certainly what diskfs does, and it's pretty important.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mai
It's not clear to me what case gets EISDIR and what case hangs. I don't
think any special case for "." or anything like that ought to be required.
I am as confused as you are. For the EISDIR failure, find where that error
is coming from. For the hang, figure out what port it is really talking t
18 matches
Mail list logo
