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. More to the point, I
was under the impression that path manipulation logic in the filing
system had limited sized buffers, which were the cause of this fault,
and that Exploder's only sin was not programming around the bug. In
fact, the more I think about it, the more sure I am that I've had to
play silly buggers on the command line myself to get around this.
Depending on the file system a program may be unable to create such
things as I mentioned. And depending on the program design it may be
reasonable to refuse to create them.
But a program should have no trouble deleting the files etc. once
they're there.
Your faith is touching, but fundamentally misplaced.
That's why the Windows API handles them just fine, while Windows
Explorer does not. You may consider, since you're unfamiliar with the
API, that mostly it's no problem doing these things in the command
interpreter, which has no special support (rather, the reason it's easy
is because it doesn't properly check command arguments). And from that
you can deduce that the API support is there.
Having stuffed this up many, many years ago, my recollection is that
it needed a certain deviousness to get around. In the case of the long
path names, my deduction from comparing the behaviours of the command
line and Explorer was that the API limited the path name length, and
Explorer didn't use relative paths to get around it. I find it hard
to call that a bug, when it's only really exposing a limitation of the
underlying FS.
For example, for general tool usage in Windows the student needs to
know about levels of environment variable specifications and file
associations, which in turn requires knowledge of processes and the
Windows registry database and various commands.
Mercifully this is rubbish. For most purposes with most tools even
Windows users don't need to know much if anything about environment
variables and the registry. Needing to know anything about the
registry is usually a sign that Windows has stuffed you up royally.
I deduce that you mainly use IDEs and don't know about the things you're
commenting on here (more than you did above). Sorry, but there it is.
You deduce incorrectly. I'd unbend enough to admit that setting
environment variables is frequently very useful to inveterate command-
line users like myself, and that Windows makes that a lot harder than
necessary, but your original statement still reads like scaremongering.
Why am I defending Windows again?
--
Rhodri James *-* Wildebeest Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list
