Terry J. Reedy added the comment:
Yes, new issue.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
___
___
Python-bugs-list mailing list
eryksun added the comment:
Nevermind, strike seems to work; it doesn't work without the \?? prefix. I
stupidly assumed the DeviceIoControl call would validate the substitute name.
Of course it doesn't; it happily creates a broken junction. Opening the
junction with CreateFile fails with
Tim Golden added the comment:
Thanks, eryksun: failed experiments are still useful data for future
reference!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
___
eryksun added the comment:
For some read Sysinternals junction utility doesn't show the raw substitute
name. Microsoft's fsutil shows the actual reparse data:
C:\mklink /J Python34 C:\Program Files\Python34
Junction created for Python34 === C:\Program Files\Python34
C:\fsutil
Roundup Robot added the comment:
New changeset 5c1c14ff1f13 by Tim Golden in branch 'default':
Issue18314 Allow unlink to remove junctions. Includes support for creating
junctions. Patch by Kim Gräsman
http://hg.python.org/cpython/rev/5c1c14ff1f13
--
Zachary Ware added the comment:
Just skimming, I noticed something about replacing calloc() with
PyMem_RawAlloc; note that there is now PyMem_Calloc or PyMem_RawCalloc that you
should be able to use if you prefer. See #21233.
--
nosy: +zach.ware
Tim Golden added the comment:
Thanks, Zach. I was aware that calloc was in the air, but I wasn't sure
if it had been committed and I'd delayed on this enough so I thought I'd
push for now. We can always revisit.
--
___
Python tracker
Roundup Robot added the comment:
New changeset e791a36ab6a2 by Tim Golden in branch 'default':
Issue18314 ACKS NEWS
http://hg.python.org/cpython/rev/e791a36ab6a2
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
Tim Golden added the comment:
Buildbots seem happy. Thanks very much for the patches!
--
resolution: - fixed
stage: patch review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
eryksun added the comment:
For a junction reparse point, Sysinternals junction.exe shows the Print Name
and Substitute Name are the same and it's not an NT \?? path (i.e.
\DosDevices, i.e. \Global??). OTOH, the substitute name does use an NT
DosDevices path when I use cmd's mklink or
Tim Golden added the comment:
Thanks for the research, eryksun. As long as it doesn't hurt let's leave
it as is for now.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
___
Kim Gräsman added the comment:
Thanks for helping me land this!
eryksun: interesting, thanks! I seem to remember having problems without the
\??\ prefix, but it could have been something else causing it (filling the
buffer to DeviceIoControl's satisfaction was... challenging.)
I have some
Tim Golden added the comment:
Yes, now that the custom allocator / tracing stuff is in place:
otherwise there's no way for custom allocation or tracing to occur.
Please go ahead and rework the patch when you have the time.
Also, since the setup of the reparse header is such an underdocumented
Kim Gräsman added the comment:
Also, since the setup of the reparse header is such an underdocumented
nightmare, please add as much commentary as possible around the choice
of allocations offsets.
I'll try. It might turn into a novel.
(BTW I'm not convinced that the PyMem change was the
Kim Gräsman added the comment:
Here's a new attempt, please let me know if this works out better.
Changes:
- Switched to CRT string functions (wcsncmp, wcscpy) instead of Windows
lstrxxxW. There was no lstrncmpW.
- Switched to PyMem_Raw(Malloc|Free) and added explicit memset after allocation
-
Tim Golden added the comment:
I'm just pinging #python-dev to see if there's a way to request a buildbot
build from a specific server-side clone.
Meanwhile, though, I definitely introduced a change into your code which I
thought I had reverted, but clearly hadn't! The code, as committed,
Kim Gräsman added the comment:
Aha, that might cause trouble.
I think you should add a memset() to sero out the newly allocated buffer also,
I think I may have used calloc to be able to assume it was initialized with
zeros.
--
___
Python tracker
Kim Gräsman added the comment:
Sorry, that wasn't clear. I mean if you change allocator _from_ calloc, make
sure the buffer is zeroed out after allocation.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
Kim Gräsman added the comment:
By the way, is PyMem_RawMalloc/PyMem_RawFree preferred for memory allocation
across the board?
If so, I can just prepare a new patch for you with that changed,
zero-initialization in place and the prefix-overrun fixed. I might get to it
tonight.
--
Roundup Robot added the comment:
New changeset 17df50df62c7 by Tim Golden in branch 'default':
Issue #18314 os.unlink will now remove junction points on Windows. Patch by Kim
Gräsman.
http://hg.python.org/cpython/rev/17df50df62c7
--
nosy: +python-dev
Roundup Robot added the comment:
New changeset 4b97092aa4bd by Tim Golden in branch 'default':
Issue #18314 Add NEWS item.
http://hg.python.org/cpython/rev/4b97092aa4bd
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
Tim Golden added the comment:
Backed out the commits after all the Windows buildbots broke. Need to look
further. (No problems on a Win7 or Ubuntu build here).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
Kim Gräsman added the comment:
Thanks for pushing this forward! Do you have links to the failing bots I could
take a look at?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
___
Tim Golden added the comment:
Here are a couple:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/4423
http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/8288
--
___
Python tracker rep...@bugs.python.org
Kim Gräsman added the comment:
Thanks!
At first I suspected 32 vs 64 bit, but the failing bots cover both...
One thing that stands out to me as risky is the memcmp() against \\??\\,
which could overrun a short src_path buffer. But I don't think that would fail
here.
I must have made some
Tim Golden added the comment:
All tests pass on 3.5 and in an unelevated prompt. I'll have a closer look at
the code tomorrow.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
___
Kim Gräsman added the comment:
ping
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
___
___
Python-bugs-list mailing list
Unsubscribe:
Kim Gräsman added the comment:
ping
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
___
___
Python-bugs-list mailing list
Unsubscribe:
Kim Gräsman added the comment:
Thanks!
There's another thing I would appreciate having somebody else test: creating
and removing junctions in a non-elevated prompt. I haven't been able to, my IT
department has trouble understanding the value of least-privilege.
--
Tim Golden added the comment:
I'll have a look at this in a week or so when I'm back on-line.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
___
Changes by Antoine Pitrou pit...@free.fr:
--
stage: test needed - patch review
versions: +Python 3.5 -Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
___
Kim Gräsman added the comment:
I really needed the well-wishing with regard to buffer sizing :-)
Here's a patch for a couple of fronts:
- Teach os.unlink about junction points
- Introduce _winapi.CreateJunction
- Introduce a new test suite in test_os.py for junction points
I pulled the
Tim Golden added the comment:
Just picking this up. Considering testing... My current proposal is to add
junction point support to _winapi, initially for the sole purpose of testing
this change, but with a view to possibly supporting it formally via the os
module. Any better ideas?
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: -haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
___
___
Python-bugs-list
Kim Gräsman added the comment:
I didn't know about _winapi; looks like a good place!
It looks like it exposes the Windows API pretty faithfully, but the junction
point stuff feels like it would be better represented as a simple
_winapi.CreateJunctionPoint(source, target) rather than
Tim Golden added the comment:
Sounds like a decent plan to me. Good luck with the buffer sizing!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
___
Kim Gräsman added the comment:
Gentle ping.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
___
___
Python-bugs-list mailing list
Kim Gräsman added the comment:
Attached is a patch that considers directory symlinks and junction points
equivalent.
I'm struggling with the test -- would it be acceptable to only run this test on
platforms that have mklink /j (Windows Vista and higher)?
I've looked at programmatic means of
Tim Golden added the comment:
I'll try to pick this one up over the next few days. Feel free to ping me if it
drops into silence!
--
assignee: - tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
Kim Gräsman added the comment:
_delete_junction_point currently shells out to a command-line tool,
junction.exe, from SysInternals. That ran fine on XP.
As I understand it, RemoveDirectoryW on XP also takes care of junction points,
but I'll find a machine to verify.
--
Changes by Terry J. Reedy tjre...@udel.edu:
--
nosy: +brian.curtin, tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
___
___
Terry J. Reedy added the comment:
I am not sure if this is a bug or enhancement. It is a moot point until there
is a patch to apply.
A patch would need a test that fails now and passes with the patch. From the
Wikipedia article, it appears that a test using mklink /J would not run on XP
and
STINNER Victor added the comment:
What is an NTFS junction point? Is it possible to delete it in cmd.exe with
the del command?
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
Tim Peters added the comment:
Victor, Wikipedia has a readable explanation:
http://en.wikipedia.org/wiki/NTFS_junction_point
I haven't used them much. From cmd.exe, I've been able to delete them, not
with del but with rmdir. You can create one from cmd.exe with the mklink
command.
Kim Gräsman added the comment:
Victor,
Junction points are like links between directories only. They've been around
since the NTFS that came with Windows 2000, but integration with OS tools has
been generally poor (e.g. Explorer wouldn't see the difference between a
junction point and a
Kim Gräsman added the comment:
This comment outlines how to tell junction points from other mount points:
http://www.codeproject.com/Articles/21202/Reparse-Points-in-Vista?msg=3651130#xx3651130xx
This should port straight into Py_DeleteFileW.
Would anyone be interested in a patch?
--
New submission from Kim Gräsman:
os.unlink currently raises a WindowsError (Access Denied) if I attempt to
unlink an NTFS junction point.
It looks trivial to allow Py_DeleteFileW [1] to remove junction points as well
as proper symbolic links, as far as I can tell.
For example, the
Kim Gräsman added the comment:
Also, I believe the reason os.unlink raises access denied is because a
junction point does not currently qualify as a directory link, so its path
is passed directly to DeleteFileW, which in turn refuses to delete a directory.
--
48 matches
Mail list logo
