|
From: Corinna Vinschen on 30 Jun 2008 12:32 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 30 Jun 2008 22:10 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 1 Jul 2008 10:47 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 1 Jul 2008 14:37 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 2 Jul 2008 06:35 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
|
Pages: 1 Prev: setting group perms on a reg entry Next: What User Logged In When No User Log In? |