On Thu, Jun 05, 2003 at 07:29:51PM +0100, Max Bowsher wrote: >Christopher Faylor wrote: >>On Thu, Jun 05, 2003 at 06:03:34PM +0100, Max Bowsher wrote: >>>Corinna Vinschen wrote: >>>>On Thu, Jun 05, 2003 at 05:25:18PM +0100, Max Bowsher wrote: >>>>>I threw together a horrible C program to ask Windows whether a file was >>>>>sparse. .exe and .dll files made with a 1.5.0 Cygwin are. I haven't >>>>>posted the test program, because it is too messy. [...] I give proof >>>>>that dll/exe files are being created sparse above. >>>> >>>>Uhm... >>> >>>I like to think that I'm sufficiently trustworthy not to lie about a >clear >>>yes/no fact. >> >>If you can't back up your conclusions with actual code why should we >>assume that you are infallible? No one is that trustworthy. > >I assumed you would trust someone telling you whether the read-only >attribute of a file was set, without needing to see further evidence? >To me, this is an equivalent situation.
Nope. I wouldn't. I'd ask for "attrib" output. That's tech support 101. And, I'd do it even though there is a system utility to do that. Strangely enough, I have this argument with our tech support guys all of the time. I recently had a situation where I lost a day of debugging because I "trusted" someone to have done the right thing and it turned out that the problem, which I couldn't duplicate, was due to someone incorrectly reporting a version number. They didn't provide the output of an rpm command or anything. They just said "I'm pretty sure it's version X". Since you have admitted to having a home-grown utility for checking the sparse file setting there is even less reason to unquestioningly believe your findings. However, If you really want to somehow be known for immense technical accuracy and proclivity, you're going to have to demonstrate it by showing more factual data and doing less "It must be bad because..." arguments. >>>Personally I think "Don't risk anything if there is no potential gain" >>>is reasonably persuasive. >> >>Lets use the popular reasoning here. If there was no potential gain >>then Microsoft would not have provided the option, would they? Since >>they did there has to be *some* potential gain. > >But their option isn't on by default. So, presumably, there must be >some circumstances when it is undesirable. That wasn't the point here. You were saying there is *no potential gain* not that there were situations in which it was undesirable. I'm just using your reasoning to show that there has to be a potential gain. I'm not necessarily agreeing with your reasoning but, IMO, you can't claim both that "If it was good Microsoft, would have turned it on by default" and "There is no potential gain", since in the former you trust Microsoft and in the latter you don't. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/