Feedback wanted on programming introduction (Python in Windows)

[Alf P. Steinbach]

* Rhodri James:
> On Fri, 30 Oct 2009 03:26:45 -0000, Alf P. Steinbach <alfps at start.no> 
> wrote:
> 
>> * Rhodri James:
>>> On Thu, 29 Oct 2009 16:53:05 -0000, Alf P. Steinbach <alfps at 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).

Given that the API level makes it possible for long paths/names to exist, a 
program should be prepared to handle them, although it may reasonably refuse to 
create them. Windows Explorer fails to handle them. Not only to create them.

A filesystem may impose a lower limit, but a program should ideally not be 
limited to or just work with a given filesystem (note: Windows supports multiple 
different filesystems, but accessed via the same general API).


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

By the facts, if I believed that most programs have no problem it would be a 
misplaced belief, yes (assuming that's what you mean above). But my argument and 
concrete example was the opposite. It expanded on my statement that

   "Unfortunately even most professional programs do not handle the requirements
   of their environs very well"

So in what you quoted above I used "should" in the sense of the ideal to strive 
for, and illustrated the harsh reality that it currently isn't that way, by the 
concrete Windows Explorer example.

This is worth keeping in mind: in a Usenet discussion, context often disappears. 
Looking up-thread is then one way to find out what it's all about. :-)


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

Yes.


<example>
C:\> md rhodri & cd rhodri

C:\rhodri> md \\?\c:\rhodri\con

C:\rhodri> dir
  Volume in drive C is maindisk
  Volume Serial Number is C469-4FA2

  Directory of C:\rhodri

01.11.2009  22:16    <DIR>          .
01.11.2009  22:16    <DIR>          ..
01.11.2009  22:16    <DIR>          con
                0 File(s)              0 bytes
                3 Dir(s)  18 405 834 752 bytes free

C:\rhodri> cd con
The system cannot find the path specified.

C:\rhodri> cd \\?\c:\rhodri\con
'\\?\c:\rhodri\con'
CMD does not support UNC paths as current directories.

C:\rhodri> rd \\?\c:\rhodri\con

C:\rhodri> _
</example>


To keep it short the above example is of something that no program really is 
expected to handle. It's just an example of the mechanisms involved. Also, it's 
nice with concrete examples, to show that one is not just blowing wind. :-)


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

No, it's not exposing a limitation of the underlying FS.

It's exposing a limitation in the way that the program deals with paths.

Apparently Windows Explorer uses fixed size buffers for paths, rather small buffers.


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

Because I used a Windows-based concrete example. Then by attempting to raise 
doubts about that which you found hard to believe, you got into an absurd 
rhetorical position. He he, it happens very often, but happily you saw it at 
once & adjusted: some folks just go on defending an indefensible position, they 
happily disregard facts and logic, and then it gets, "interesting". :-)


Cheers,

- Alf