From: Corinna Vinschen on
Corinna Vinschen wrote:
> Hi Jefferey,
>
> "Jeffrey Tan[MSFT]" wrote:
>> Hi Corinna,
>>
>> Yes, I am hoping so either. However, it seems that I get very few email
>> responses from product team for your questions; I think this is because
>> your questions are mostly non-trivial questions(It may cost a lot of time
>> for them to find out the root cause) which need high technical level
>> knowledge :-).
>>
>> If you got the root cause/confirmation from the CSS/product team, please
>> feel free to share in the newsgroup. Thanks!
>
> Yes, I'll certainly share the results with the newsgroup.

It took a long time, but here we go.

No debugging, no root cause, no fix. The guys responsible for the file
system are of the opinion that the bad timing behaviour is the result of
a natural evolution of the file system over time, and not actually a
bug. Case closed. :(


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
From: Alexander Grigoriev on
No way. Did it actually got up to the developers, or it was a treage guy,
who doesn't even have source access (they're usually only able to give some
BS). Time to raise a stink?

"Corinna Vinschen" <corinna(a)community.nospam> wrote in message
news:g4b1r1$hrn$1(a)perth.hirmke.de...
> Corinna Vinschen wrote:
>> Hi Jefferey,
>>
>> "Jeffrey Tan[MSFT]" wrote:
>>> Hi Corinna,
>>>
>>> Yes, I am hoping so either. However, it seems that I get very few email
>>> responses from product team for your questions; I think this is because
>>> your questions are mostly non-trivial questions(It may cost a lot of
>>> time
>>> for them to find out the root cause) which need high technical level
>>> knowledge :-).
>>>
>>> If you got the root cause/confirmation from the CSS/product team, please
>>> feel free to share in the newsgroup. Thanks!
>>
>> Yes, I'll certainly share the results with the newsgroup.
>
> It took a long time, but here we go.
>
> No debugging, no root cause, no fix. The guys responsible for the file
> system are of the opinion that the bad timing behaviour is the result of
> a natural evolution of the file system over time, and not actually a
> bug. Case closed. :(
>
>
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Project Co-Leader
> Red Hat


From: Corinna Vinschen on
Alexander Grigoriev wrote:
> "Corinna Vinschen" <corinna(a)community.nospam> wrote in message
>> No debugging, no root cause, no fix. The guys responsible for the file
>> system are of the opinion that the bad timing behaviour is the result of
>> a natural evolution of the file system over time, and not actually a
>> bug. Case closed. :(
>>
>>
>> Corinna
>
> No way. Did it actually got up to the developers, or it was a treage guy,
> who doesn't even have source access (they're usually only able to give some
> BS). Time to raise a stink?

I can't really tell, but I assume he had no source access. He did
reproduce the problem and, from what he told, followed on with the
people working on kernel and file system. The reply is supposedly from
them. I tried multiple times to make my point clear, that quadratic
timing behaviour in the FS should be considered a bug, but to no avail.
Even *if* it would have been considered a bug, there would probably no
fix because "it is a very niche case and has a high "risk" factor as it
could involve changing very fundamental and stable parts of the
operating system." From the whole discussion I'm under the impression
that nobody really even tried to find the root cause. I guess that it's
just not important enough, given that 99% of the users are only
using paths up to 260 chars anyway.

What do you mean by "Time to raise a stink" and how would I do that?


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
From: David Craig on
I have heard you can dispute the solution and either get your incident
refunded to you or get it elevated.

I have written code to create pathnames using paths that repeated recurse
down a string that just gets repeated as a subdirectory entry until I get 20
or 30 levels deep. Then using streams to get a total of about a 20K
characters in the full path name. It is a real pain to manually delete the
tree since most of the OS provided tools don't work at that depth/length.

"Corinna Vinschen" <corinna(a)community.nospam> wrote in message
news:g4dg1f$k3i$1(a)perth.hirmke.de...
> Alexander Grigoriev wrote:
>> "Corinna Vinschen" <corinna(a)community.nospam> wrote in message
>>> No debugging, no root cause, no fix. The guys responsible for the file
>>> system are of the opinion that the bad timing behaviour is the result of
>>> a natural evolution of the file system over time, and not actually a
>>> bug. Case closed. :(
>>>
>>>
>>> Corinna
>>
>> No way. Did it actually got up to the developers, or it was a treage guy,
>> who doesn't even have source access (they're usually only able to give
>> some
>> BS). Time to raise a stink?
>
> I can't really tell, but I assume he had no source access. He did
> reproduce the problem and, from what he told, followed on with the
> people working on kernel and file system. The reply is supposedly from
> them. I tried multiple times to make my point clear, that quadratic
> timing behaviour in the FS should be considered a bug, but to no avail.
> Even *if* it would have been considered a bug, there would probably no
> fix because "it is a very niche case and has a high "risk" factor as it
> could involve changing very fundamental and stable parts of the
> operating system." From the whole discussion I'm under the impression
> that nobody really even tried to find the root cause. I guess that it's
> just not important enough, given that 99% of the users are only
> using paths up to 260 chars anyway.
>
> What do you mean by "Time to raise a stink" and how would I do that?
>
>
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Project Co-Leader
> Red Hat


From: Corinna Vinschen on
David Craig wrote:
> I have heard you can dispute the solution and either get your incident
> refunded to you or get it elevated.
>
> I have written code to create pathnames using paths that repeated recurse
> down a string that just gets repeated as a subdirectory entry until I get 20
> or 30 levels deep. Then using streams to get a total of about a 20K
> characters in the full path name. It is a real pain to manually delete the
> tree since most of the OS provided tools don't work at that depth/length.

Ok, I have just re-opened the case. I have no idea if anything comes out
of it, but I'll try.


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat