Roundup Robot added the comment:
New changeset d094eeeb1496 by Steve Dower in branch 'default':
Closes #9445: Removes detection of GetFinalPathNameByHandle
https://hg.python.org/cpython/rev/d094eeeb1496
--
nosy: +python-dev
stage: patch review - resolved
status: open - closed
Mark Lawrence added the comment:
I believe that this can be closed as fixed, would someone like to do the
honours please.
--
nosy: +steve.dower, tim.golden, zach.ware
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9445
Steve Dower added the comment:
The patch is obsolete, but Martin is correct - we can drop the detection
completely. Any concerns?
(Reading through the issue, there may be some value in a more general
GetFinalPathNameByHandle wrapper that can get VOLUME_NAME_DOS if available and
Mark Lawrence added the comment:
I believe that this specific issue can be closed but is a follow up needed
regarding problems mentioned in msg114084 ?
--
nosy: +BreamoreBoy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9445
Ezio Melotti added the comment:
The original issue seems to be fixed, but the other two related issues
mentioned by Amaury still need to be addressed. One has already a patch, the
other doesn't.
--
components: +Extension Modules -Build
type: compile error - resource usage
versions:
Martin v. Löwis added the comment:
I believe the patch is obsolete. Python does not support Windows XP anymore, so
all supported versions provide GetFinalPathNameByHandle, and all the detection
code can go.
--
nosy: +loewis
___
Python tracker
Ezio Melotti added the comment:
Is this issue still valid?
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9445
___
___
Brian Curtin cur...@acm.org added the comment:
Your patch works for me on Win7.
I'll put together a patch for the malloc/free thing in your first bullet point.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9445
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Can someone explain why among the 6 calls to Py_GetFinalPathNameByHandle, 5 of
them use VOLUME_NAME_DOS and only one uses VOLUME_NAME_NT?
--
nosy: +amaury.forgeotdarc
status: closed - pending
Brian Curtin cur...@acm.org added the comment:
I committed the code you speak of (posix__getfinalpathname in
Modules/posixmodule.c), but I don't know if I have a great answer for that
question. It looks like VOLUME_NAME_NT (path with volume device path) should
just be changed to
Jason R. Coombs jar...@jaraco.com added the comment:
In the case where I did use VOLUME_NAME_NT, I think I chose it because it
returned a more robust result. That is, it's not clear what the result is if
the result is not on a volume that is assigned a drive letter, but all files
referenced
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
The calls to Py_GetFinalPathNameByHandle come in pairs: one to get the length,
the other to retrieve the value. They should at least be consistent.
There are two other issues:
- in all three places, it's possible for the function to
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Applied in r84356.
Thank you.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9445
New submission from Brian Curtin cur...@acm.org:
Raymond informed me that #1578269 introduced breakage to compilation under
Visual Studio 2005 due to three undefined symbols. I'm not currently setup to
build under 2005, so I just offer this patch which defines the values as they
are seen in
14 matches
Mail list logo
