* Rhodri James:
On Sun, 01 Nov 2009 21:20:20 -0000, Alf P. Steinbach <al...@start.no>
wrote:
* Rhodri James:
This is a weird attribution style, by the way. I don't think it helps.
That's a pretty weird thing to comment on.
And as far as I can see the comment doesn't make sense except as an attempt to
find something negative to say.
But anyway, the point about '*' was, once upon a time, that it made for a very
clear style of quoting in old newsreaders. Nowadays the tools are generally of
lesser quality (e.g. I'm using Thunderbird). And so it doesn't really have much
of that advantage left, but I'm using it anyway; I can be pretty stubborn about
issues of quality.
On Fri, 30 Oct 2009 03:26:45 -0000, Alf P. Steinbach <al...@start.no>
wrote:
* Rhodri James:
On Thu, 29 Oct 2009 16:53:05 -0000, Alf P. Steinbach
<al...@start.no> wrote:
with the best knowledge of the program's environment, is unable to
handle (such as delete) files or folders with paths greater than
some 260 characters, is unable to handle filenames that differ
only in case and are in the same directory, and is unable to e.g.
delete a folder called "con" -- although such files & folders
can very easily be created.
You may or may not be aware that some of these things are
limitations of
the underlying disc format,
Sorry no, it isn't.
Even assuming you meant the more reasonable "file system", no, it
isn't.
Actually I should have mentioned the filing system as well as the disc
format (which does matter). I may not be using correct Windows
terminology,
since I'm referring to both the bytes on hardware and the software stack
that terminates in the OS API.
Still, colour me surprised. I had assumed that NTFS had some (large)
limit on filenames, and 256 sounded plausible.
For NTFS it's 32K or 64K wide characters, I don't recall which. But
what's important is that that's also the API level limit. You can find
most of the details in Microsoft's documentation of CreateFile (but
it's off-topic here).
Actually it [the limit]'s not
You're disputing a plain fact.
For which you've been given a technical reference, as well as concrete example.
I'm sorry, but it's idiotic to dispute plain facts.
, since it's a perfect example of the "not reading quite
carefully enough" others have pointed out before. You make this statement
as an absolute, iron-clad assertion. Checking the MS website, we find it
actually says:
"Maximum Path Length Limitation
In the Windows API (with some exceptions discussed in the following
paragraphs), the maximum length for a path is MAX_PATH, which is defined
as 260 characters."
The exceptions are unicode versions of some of the functions, which do
give you ~32K characters. However, the docs are pretty specific about
what is and isn't the API limit.
I'm sorry but you're misunderstanding the documentation.
In your own words, you're "not reading quite carefully enough".
By the way, your technique of vague ad hominem attack here is detestable.
But anyway, if you read the documentation of CreateFile as I directed you to, or
simply read on where you was, then you get a more technically correct picture.
Or, by applying logic you can /deduce/ that since >260 character paths can and
do exist, 260 characters is not "the limit".
The MS documentation is unfortunately not all that clear. In many cases (the
most infamous one is perhaps the claim that a program's entry point is WinMain)
it's just plain incorrect, being written by technical writers. But it's simple
enough to write a few programs to check it out.
Since this applies to the command
line just as much as to GUIs,
No, it doesn't. And you've been given a concrete example of how.
You can't just go on *inventing* facts.
Facts are facts, your fantasies & wishes are your fantasies & wishes.
I'll repeat my claim that blaming Explorer
for something that causes just as much grief on a command line is a
tad unfair.
I'm sorry, but there's a complete lack of logic in that, as well as
misdirection.
First, regarding the misdirection, it is untrue that I have "blamed" Windows
Explorer for this. The blame, if any is to be affixed anywhere, belongs
elsewhere than with a computer program.
Second, regarding the logic, that a program exhibits low quality in some respect
is not OK just because there's another program that also exhibits low quality.
More importantly, I accuse you of making very definitive statments
that turn out to be insufficiently researched.
That would be OK and what I want. :-) But you haven't. You're making general
vague statements about quality, but haven't addressed any concrete thing in the
text. And what you have responded to here in this thread, it's all been
incorrect. In this latest article you have even started disputing simple
technical facts and started making fallacious deductions, shown above.
That's not an
encouraging state of affairs in someone planning to write a beginners'
textbook. Having originally learned C from one of Herbert Schildt's
books, I reckon I've earned the right to be highly allergic to this!
I'm sorry to hear that you had to endure that.
It's an old saying that the low price of Herbert's annotated C++ reference,
compared to the official standard, reflected the value of his annotations...
But that's no excuse to now start emulating Herbert, regarding blatant disregard
for facts and logic, as you've done above.
Cheers & hth.,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list
