This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Sparse file criteria malfunction - binutils produces sparse .exe & .dll files

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.
>>>I like to think that I'm sufficiently trustworthy not to lie about a
>>>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..."

>>>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.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]