I can reproduce the bug on snv_82, but not the "fix".
However, enabling fbt::: (even with predicate) on my system slows down
my mkdir and ls commands by a factor of 10x or more.
Interestingly, if I use the "foldcase" mount option and then use "mkdir
.net" but leave .NET in the ls and rmdir commands, it works. However, it
is still broken for "mkdir .NET".
It would seem that there bug is is the PCFS implementation in any case
(e.g. why does mkdir return with out an error, and yet the directory has
not been created).
Your test seems to indicate there is also a race condition, which hides
the bug, and which your fbt::: probe effect opens the window for. Quite
bizzarre!
What happens if you insert a "sleep 1" in the loop between the mkdir and ls?
How on earth did you stumble on this?
Phil
Martin Cerveny wrote:
Hello.
The PCFS filesystem does not create files/dirs like ".NET" :-)
Ok, I tried to dtrace PCFS flow in kernel, BUT if I run dtrace oneliner, the
PCFS works.
Can someone explain me why dtrace (non destructive) influences functionality of
kernel ??
M.C>
(attached output on my snv_123)
------------------------------------------------------------------------
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
