forwarded 306210 http://sourceforge.net/tracker/index.php?func=detail&aid=1235337&group_id=2435&atid=102435 thanks
On Tue, Feb 07, 2006 at 11:49:26AM +0100, Richard Atterer wrote: > I'm sorry, I've just tested it and it still doesn't work. :-/ I compiled my > example program using mingw 3.4.5.20060117.1-1, mingw32-binutils > 2.16.91-20060119.1-1 and mingw32-runtime 3.9-3, then ran it on an NTFS > partition on a Windows XP system. > > The program wrote 4294963200 bytes of data (that's 0xFFFFF000), then exited > with: > -1 > strerror: no space left on device Gack. Ok, I figured wine was right with either one or the other. The file (size) written must have been a figment of its imagination. > Did you actually apply my patch? No. You also filed it upstream, so I deferred it to whatever their solution would be. I was running a bunch of test cases on the new release, including yours -- which wasn't clear whether it succeeded or failed. I figured you'd get the memo and if need be, we'd reopen, lather, repeat, as required. Like this ;-) > Unfortunately, upstream seems to ignore my > bug report (no followups on > <http://sourceforge.net/tracker/index.php?func=detail&aid=1235337&group_id=2435&atid=102435>), > maybe you could prod them about it? I've got a couple of other bugs on the roll there for w32api, I'll see what I can learn. > BTW, this bug should probably be reassigned to mingw and not libstdc++, > because according to <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22388#c3> > the respective bug is in mingw-specific modifications to the standard > libstdc++. How many places did you spray this report? Looking at this one you just answered your own question (and mine) from above: (thanks ;-) ------- Comment #1 From Danny Smith 2005-07-09 23:11 [reply] ------- mingw runtime does not have struct stat64 or fstat64(), so this define is not correct. In fact the native build of libstdc++ fails the _GLIBCXX_USE_LFS configure test. (mingwt does have struct _stati64 and _fstati64() which would work in __basic_file<char>::showmanyc) Danny Which doesn't look to me like ignoring it at all. He simply claims it is wrong. Which fairly simply convinces me not to apply it. Did you ask him about what the correct solution might be? Proof by Works For Me is not sufficient here. I think the onus to learn more is back on you in the light of this... > > The test case you posted, when run under wine, writes out a file > > of 4294971402 bytes -- and though the output there is still not > > correct > > I don't think wine is a good test platform for this kind of thing. :-/ No. But it is all I have in front of me. And its been a reasonable bet that things which _do_ work properly on it, also work ok elsewhere. In this case, it seems (postmortem) to have more or less done the right thing on both sides of the fence (written a large file to linux, and failed to read it in the (PE) process). I needed someone to cross check that to put the result I had in perspective. Sorry its still not fixed -- but I think you are going to have to look a bit harder for a more suitable fix. I'm pretty sure Danny might know about some code paths you haven't chosen to look down yet, so if he has doubts, I certainly share them. To convince me, you'll have to convince him. I'm going to mark this one forwarded, Danny appears to have taken responsibility for it and left it open, so I can only assume he plans to fix it properly some day when he has time. The best way to accelerate that is probably ask what needs to be done and promptly do it. Prodding busy people doesn't make them go faster. But giving them what they need, when they need it, clearly does. Thanks! Ron (who'll probably otherwise keep pinging you on the status of new uploads while wine is indecisive ...) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
