On Mon, Nov 20, 2000 at 09:32:39AM +0100, Eric Paire wrote:
> >
> > On Fri, 17 Nov 2000, Guest section DW wrote:
> >
> > > I see that an entire discussion has taken place. Let me just remark this,
> > > quoting the Austin draft:
> > >
> > > If the path argument refers to a path whose final comp
>
> On Fri, 17 Nov 2000, Guest section DW wrote:
>
> > I see that an entire discussion has taken place. Let me just remark this,
> > quoting the Austin draft:
> >
> > If the path argument refers to a path whose final component is either
> > dot or dot-dot, rmdir( ) shall fail.
> >
> > EINVAL
On 18 Nov 2000, Nix wrote:
> Alexander Viro <[EMAIL PROTECTED]> writes:
>
> > If every way from foo to target goes through the source rename(source,target)
> > _will_ make the graph disconnected. Checking that for generic DAG is a hell.
>
> Why do you say this? Algorithms for cycle detection
Alexander Viro <[EMAIL PROTECTED]> writes:
> If every way from foo to target goes through the source rename(source,target)
> _will_ make the graph disconnected. Checking that for generic DAG is a hell.
Why do you say this? Algorithms for cycle detection are comparatively
computationally expensiv
On Fri, 17 Nov 2000, Guest section DW wrote:
> I see that an entire discussion has taken place. Let me just remark this,
> quoting the Austin draft:
>
> If the path argument refers to a path whose final component is either
> dot or dot-dot, rmdir( ) shall fail.
>
> EINVALThe path argu
On Thu, Nov 16, 2000 at 02:47:35PM +0100, Jean-Marc Saffroy wrote:
> As you see, it looks like the rmdir fails simply because the dir name ends
> with a dot !! This is confirmed by sys_rmdir in fs/namei.c, around line
> 1384 :
>
> switch(nd.last_type) {
> case LAST_DOTDOT
On Thu, 16 Nov 2000, David Feuer wrote:
> At 06:10 PM 11/16/2000 -0500, you wrote:
> >Here's one more: you can't rename across the binding boundary. They _are_
> >mounts, so they avoid all that crap with loop creation on rename, etc.
> >Take a generic DAG and try to implement rename() analog on
At 06:10 PM 11/16/2000 -0500, you wrote:
>Here's one more: you can't rename across the binding boundary. They _are_
>mounts, so they avoid all that crap with loop creation on rename, etc.
>Take a generic DAG and try to implement rename() analog on it. Have fun
>catching the cases that would make t
On 16 Nov 2000, H. Peter Anvin wrote:
[hardlinks on directories]
> I don't believe it's inherently impossible in Linux anymore. In fact,
Yes, it is. bindings are asymmetrical. And that's the reason why they
work while links to directories do not.
> vfsbinds provide a lot of the same kind o
Followup to: <[EMAIL PROTECTED]>
By author:David Feuer <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> . and foo/. are also links, not directories... the directories themselves
> are filesystem internal objects, and not discussed by the standard. I
> didn't know that linux supporte
At 07:51 PM 11/16/2000 +0100, you wrote:
>Now I see your point : by "." or "foo/." you mean the directory itself,
>while "foo" or "foo/" refer to the link to the directory, and they are
>obviously different objects... at least since hard links on directories
>were introduced. Fine.
. and foo/. ar
On Thu, 16 Nov 2000, Jean-Marc Saffroy wrote:
> Now I see your point : by "." or "foo/." you mean the directory itself,
> while "foo" or "foo/" refer to the link to the directory, and they are
> obviously different objects... at least since hard links on directories
> were introduced. Fine.
So
On Thu, 16 Nov 2000, Alexander Viro wrote:
> > This is a point I don't understand here : do you mean that they are
> > confused if they can rmdir "." but not if they can rmdir their cwd
> > differently ? What's the difference ?
>
> rmdir() is _not_ "kill the directory identified by name and remo
On Thu, 16 Nov 2000, Jean-Marc Saffroy wrote:
> On Thu, 16 Nov 2000, Linus Torvalds wrote:
>
> > The cwd is not the problem. The '.' is.
> >
> > The reason for that check is that allowing "rmdir(".")" confuses a lot of
> > UNIX programs, because it wasn't traditionally allowed.
>
> This is a
On Thu, 16 Nov 2000, Linus Torvalds wrote:
> The cwd is not the problem. The '.' is.
>
> The reason for that check is that allowing "rmdir(".")" confuses a lot of
> UNIX programs, because it wasn't traditionally allowed.
This is a point I don't understand here : do you mean that they are
confus
On Thu, 16 Nov 2000, Linus Torvalds wrote:
> The cwd is not the problem. The '.' is.
>
> The reason for that check is that allowing "rmdir(".")" confuses a lot of
> UNIX programs, because it wasn't traditionally allowed.
Moreover, allowing it means that you overload the semantics of rmdir()
(
Jean-Marc Saffroy <[EMAIL PROTECTED]>:
>
> It looks like the rmdir syscall behaves strangely in 2.4 kernels :
>
> saffroy@sisley:~> uname -a
> Linux sisley 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST 2000 i686 unknown
> saffroy@sisley:/tmp> mkdir foo
> saffroy@sisley:/tmp> rmdir foo/.
> saffroy@
On Thu, 16 Nov 2000, Jean-Marc Saffroy wrote:
>
> As you see, it looks like the rmdir fails simply because the dir name ends
> with a dot !! This is confirmed by sys_rmdir in fs/namei.c, around line
> 1384 :
>
> switch(nd.last_type) {
> case LAST_DOTDOT:
>
Hello,
It looks like the rmdir syscall behaves strangely in 2.4 kernels :
saffroy@sisley:~> uname -a
Linux sisley 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST 2000 i686 unknown
saffroy@sisley:/tmp> mkdir foo
saffroy@sisley:/tmp> rmdir foo/.
saffroy@sisley:/tmp> mkdir foo
saffroy@sisley:/tmp> cd
19 matches
Mail list logo
