Strange "feature" involving double slashes in Win98

C

Carlos Ribeiro

Hello all.

I'm sending this to the list because I would like to know if someone
else has ever stumbled across this one, and also because one possible
solution is to patch, or simply "decorate", some of the Python
libraries functions (a few of the os and os.path calls). Note: if
you're going to reply, please read it *all* before doing so -- I've
already explored this problem quite a bit, and found no obvious
solution to it yet.

** The problem **

I am evaluating DrPython, one of the many IDEs available now. I had a
problem with it that I was able to track down to the particular way
the pathnames use by the program are constructed. To make a long story
short, Windows 98 doesn't like pathnames in the following format:

slashes: "c://somedir"
backslashes: r"c:\\somedir"

(it doesn't matter if the string is provided with forward or back
slashes. If the double slash is located immediately after the drive
letter+comma, then it bombs. The result can be a weird immediate
error, but in some cases one has to expect for a long timeout. Double
slashes of any sort are permitted in the middle of the pathname,
though)

The problem seems to have an obvious explanation. As probably everyone
knows, Windows uses a double slash notation for the machine name in
SMB shares. But wait -- the pathname includes a drive letter, so it
must not be a SMB share name! Or could it be? I never had seen before
a share named like this:

c:\\machinename\somedir

I really don't know if the pathname above is valid in SMB or not. But
I have good reason to believe that it should be invalid, as it makes
no sense (because of the drive letter, of course). Knowing that, the
problem can be reproduced in the DOS prompt quite easily:

a) cd c:\\windows --> fails with an "invalid folder" message
b) cd c:\\[my_workstation_name] --> abort, retry or ignore

Example (b) failed that way because I have disabled file serving in my
PC. But it's strange to note that it handled it differently just
because I used my own workstation name. I also don't know if this that
way problem affects other versions of Windows besides Win98SE. If you
try it, please let me know.

** Solving the problem **

DrPython relies on string concatenation to build new pathnames. My
root dir is "c:/", and at some places in the code, other pieces are
concatenated to it, causing the problem. In Unix it doesn't happen --
double slashes are fine anywhere. Knowing that, there are three
possible solutions for the problem:

1) Never write pathnames starting with double slashes.

It should be easy... but remember, I'm dealing with third party code
here. It will take some time for me to find out and correct all the
places where os functions are called with a pathname. I have tried to
do it, in fact, but still DrPython freezes from time to time due to
this problem as I find yet another place where a pathname is build
from the concationation of small pieces.

2) Fix os calls to correct the problem.

Not really sure about it... because I'm afraid that not this is not
going to ship with the standard Python library. After all, it's a
Windows bug.

3) Decorate os calls to correct the problem.

For now, that's my best bet for a generic solution that doesn't break
anyone else's code. I can write a wrapper for some of the affected OS
calls, and eliminate the double slashes out of the pathname before
calling the original function. It might work , but I still have to
test it.


Well, that's the problem. What's I'm supposed to do?



--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)
 
J

Jeff Shannon

Carlos said:
** Solving the problem **

DrPython relies on string concatenation to build new pathnames. My
root dir is "c:/", and at some places in the code, other pieces are
concatenated to it, causing the problem.

It seems to me that the problem, here, is that DrPython *should* be
using os.path.join() to build those pathnames, instead of
concatenation. (os.path.join() intelligently removes duplicate
directory separators.) That may not help you much, though, since that's
not your code. (If you're not already reporting this as a [series of]
bug in DrPython, you probably should...)

Given that fixing DrPython isn't a very practical option for you, I'd
say that wrapping the os module may be the best option left, but I'm not
sure how one would go about that. Given that os is a built-in module,
you'd probably have to pull some trickery with sys.modules once the
interpreter was started, and I don't understand that whole process well
enough to be able to offer specific advice.

Jeff Shannon
Technician/Programmer
Credit International
 
D

Diez B. Roggisch

Well, that's the problem. What's I'm supposed to do?

Maybe you can go for applying os.path.join and os.path.normpath to all
user-specified paths? I don't have windows, so I can't say how
os.path.normpath('c://foo') behaves, but maybe its does do the job.
 
J

Jeff Shannon

Carlos said:
a) cd c:\\windows --> fails with an "invalid folder" message
b) cd c:\\[my_workstation_name] --> abort, retry or ignore

Additionally, as an extra data point, both of these failed with "The
system cannot find the path specified" on my Win2K machine, so it's not
just a Win9x issue. (I'm not sure if the fact that they're different
errors on your machine but the same error on my machine is significant,
but in either case it's still nonfunctional.)

Jeff Shannon
Technician/Programmer
Credit International
 
P

Peter Hansen

Diez said:
Maybe you can go for applying os.path.join and os.path.normpath to all
user-specified paths? I don't have windows, so I can't say how
os.path.normpath('c://foo') behaves, but maybe its does do the job.

c:\>python
Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.'c:\\somepath'

Seems that normpath isn't up to the job, but abspath would be... if
it doesn't cause other problems. Since we're inherently dealing
with absolute paths for this problem, maybe it's adequate?

-Peter
 
C

Carlos Ribeiro

Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on
win32
(...)'c:\\somepath'

Strange. I've tried it here with different results.

ActivePython 2.3.2 Build 232 (ActiveState Corp.) based on
Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit (Intel)] on win32'c:\\\\work'

Of course, I'm not using the same build as you. Either there was some
bugfix inbetween 2.3.2 and 2.3.4, or the underlying libraries used by
ActivePython and standard Python differ in this regard (not highly
probable, anyway). I'm not sure.


--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)
 
P

Peter Hansen

Carlos said:
'c:\\somepath'
>
Strange. I've tried it here with different results.

ActivePython 2.3.2 Build 232 (ActiveState Corp.) based on
Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit (Intel)] on win32

'c:\\\\work'

Of course, I'm not using the same build as you. Either there was some
bugfix inbetween 2.3.2 and 2.3.4, or the underlying libraries used by
ActivePython and standard Python differ in this regard (not highly
probable, anyway). I'm not sure.

Do you have pywin32 (win32all) installed? Try this one instead:

win32api.GetFullPathName('c://work')

This does the same as abspath does above, on mine. I ask because
of stuff in ntpath.py which appears to be calling the equivalent
of that instead of the normpath(join(getcwd(), path)) approach that
the docs note is equivalent...

-the-blind-leading-the-blind-ly y'rs,
Peter
 
C

Carlos Ribeiro

Do you have pywin32 (win32all) installed? Try this one instead:

win32api.GetFullPathName('c://work')

This does the same as abspath does above, on mine. I ask because
of stuff in ntpath.py which appears to be calling the equivalent
of that instead of the normpath(join(getcwd(), path)) approach that
the docs note is equivalent...

You're right. That's what I got now:

PythonWin 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit
(Intel)] on win32.
Portions Copyright 1994-2001 Mark Hammond ([email protected])
- see 'Help/About PythonWin' for further copyright information.'c:\\\\work'

It seems that either ActivePython uses a different implementation for
os.abspath(), or the code changed between 2.3.2 and 2.3.4. The last
time I checked ActivePython was still using 2.3.2 -- I'll check it out
again, and upgrade if a newer version is available.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)
 
P

Peter Hansen

Carlos said:
Do you have pywin32 (win32all) installed? Try this one instead:
win32api.GetFullPathName('c://work')

This does the same as abspath does above, on mine.

You're right. That's what I got now:

PythonWin 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit
(Intel)] on win32.
'c:\\\\work'

It seems that either ActivePython uses a different implementation for
os.abspath(), or the code changed between 2.3.2 and 2.3.4. The last
time I checked ActivePython was still using 2.3.2 -- I'll check it out
again, and upgrade if a newer version is available.

I reach a different conclusion. Note that when I said "this
does the same as abspath does above", I meant that *my* output
for the GetFullPathName() call is actually this:

'c:\\work'

In other words, it appears to be an OS difference. What flavour
and version of Windows are you running? I'm using XP Pro SP2.

-Peter
 
C

Carlos Ribeiro

Oops. For some reason I misread your message. I'm using Win98 SE, and
have no plans to upgrade (at least while I'm limited to my current PC
setup).

Regarding this bug: if it's clear that this is Windows bug, does it
make sense to fix it in the libraries themselves? The bug exists, but
it doesn't affect much software because few people do things the
"wrong" way. A note in the documentation is more than enough to
clarify the actual workings of the code in the case of Win9x. I'll
report the bug to the DrPython guys, and let them solve the particular
issue with their software. I fixed the problem in a couple of
locations but I'm not sure if I found all relevant places.


Carlos said:
Do you have pywin32 (win32all) installed? Try this one instead:
win32api.GetFullPathName('c://work')

This does the same as abspath does above, on mine.

You're right. That's what I got now:

PythonWin 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit
(Intel)] on win32.
import win32api
win32api.GetFullPathName('c://work')

'c:\\\\work'

It seems that either ActivePython uses a different implementation for
os.abspath(), or the code changed between 2.3.2 and 2.3.4. The last
time I checked ActivePython was still using 2.3.2 -- I'll check it out
again, and upgrade if a newer version is available.

I reach a different conclusion. Note that when I said "this
does the same as abspath does above", I meant that *my* output
for the GetFullPathName() call is actually this:

'c:\\work'

In other words, it appears to be an OS difference. What flavour
and version of Windows are you running? I'm using XP Pro SP2.

-Peter



--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)
 
P

Peter Hansen

Carlos said:
Oops. For some reason I misread your message. I'm using Win98 SE, and
have no plans to upgrade (at least while I'm limited to my current PC
setup).

Regarding this bug: if it's clear that this is Windows bug, does it
make sense to fix it in the libraries themselves?

Not sure, but one could argue that if the OS routine to do this is
buggy, the code that was put in to take advantage of it should be
removed and a different approach taken. Or if it's important
enough, a special case could be inserted. I suspect your opinion
is valid on this: too few places have paths that look like c://work
to bother fixing this.

-Peter
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,764
Messages
2,569,566
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top