Mailing List Archive: 2.2.0pre8: mkdir "." returns ENOENT instead of EEXIST

2.2.0pre8: mkdir "." returns ENOENT instead of EEXIST

Jan 19, 1999, 9:43 AM

Post #1 of 4 (390 views)

Linux linux-2.2.0pre8 "mkdir ." return ENOENT instead of
EEXIST. This breaks the latest version of CVS when used on a local
repository. Linux-2.2.0pre7 did not appear to have this problem,
and I have definitely confirmed that pre2 did not have this problem.
If this change is a correction mandated by some standard,
then I am happy to patch cvs to fix the problem. However, I think
this is probably a bug in the changes to fs/namei.c.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
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/

Re: 2.2.0pre8: mkdir "." returns ENOENT instead of EEXIST [ In reply to ]

manolow at step

Jan 19, 1999, 10:56 AM

Post #2 of 4 (392 views)

Permalink

"Adam J. Richter" wrote:
>
> Linux linux-2.2.0pre8 "mkdir ." return ENOENT instead of
> EEXIST. This breaks the latest version of CVS when used on a local
> repository. Linux-2.2.0pre7 did not appear to have this problem,
> and I have definitely confirmed that pre2 did not have this problem.
[...]
Not in my pre8
-------------------
# mkdir .
mkdir: cannot make directory `.': File exists
-------------------
-
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/

Re: 2.2.0pre8: mkdir "." returns ENOENT instead of EEXIST [ In reply to ]

adam at yggdrasil

Jan 19, 1999, 12:00 PM

Post #3 of 4 (396 views)

Permalink

>On 1999-01-19 at 08:43:58, Adam J. Richter wrote:
>> Linux linux-2.2.0pre8 "mkdir ." return ENOENT instead of
>> EEXIST. This breaks the latest version of CVS when used on a local
>> repository. Linux-2.2.0pre7 did not appear to have this problem,
>> and I have definitely confirmed that pre2 did not have this problem.
Janos Farkas <chexum@shadow.banki.hu> wrote:
>When this happens, by chance, isn't "." a mount point? I can reproduce
>this, but only when trying to create a file/directory which is a mount
>point, and reported also to linux-kernel; it's probably the new
>check_parent() macro failing to take into account the specialities of
>mount points...
Yes, you're right. The problem only occurs on a mount point. This
problem (at least the manifestation in CVS) did not occur in 2.2.0-pre7,
and I have confirmed that even on a mount point it definitely does
not occur in 2.2.0-pre3. Thanks for narrowing it down.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
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/

Re: VM20 behavior on a 486DX/66Mhz with 16mb of RAM [ In reply to ]

jalvo at cloud9

Jan 19, 1999, 1:09 PM

Post #4 of 4 (391 views)

Permalink

On Tue, 19 Jan 1999, Stephen C. Tweedie wrote:
> Hi,
>
> On Sat, 16 Jan 1999 14:22:10 +0100 (CET), Andrea Arcangeli
> <andrea@e-mind.com> said:
>
> > Setting an high limit for the cache when we are low memory is easy doable.
> > Comments from other mm guys?
>
> Horrible --- smells like the old problem of "oh, our VM is hopeless at
> tuning performance itself, so let's rely on magic numbers to constrain
> it to reasonable performance". I'd much much much much rather see a VM
> which manages to work well without having to be constrained by tricks
> like that (although by all means supply extra boundary limits for use in
> special cases: just don't enable them on a default system).
>
We have at least one other case where a memory algorithm needed to be
tuned for smaller memory. It was the "target free space per cent" which
had to be larger for small memory machines. There could be a similiar
effect in cache handling. No problem on larger machines, but a big problem
on small memory machines.
John Alvord
Music, Management, Poetry and more...
http://www.candlelist.org/kuilema

Cheap CDs @ http://www.cruzio.com/~billpeet/MusicByCandlelight

-
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/