Kim Gräsman added the comment:
Thanks! I filed this so long ago that I'd forgotten about it.
I ran the code in question with your patch manually hacked into my Python
installation (3.4.1) and output is much easier to digest now.
I don't have a strong opinion on key names -- I have
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
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 alloc
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
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
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
<http://bugs.python.org/is
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:
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
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
<http://bugs.python.org/issue18
Kim Gräsman added the comment:
ping
--
___
Python tracker
<http://bugs.python.org/issue18314>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Kim Gräsman added the comment:
ping
--
___
Python tracker
<http://bugs.python.org/issue18314>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
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
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 pulle
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
Kim Gräsman added the comment:
Gentle ping.
--
___
Python tracker
<http://bugs.python.org/issue18314>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 programmati
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 v
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 p
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
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
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 ntfslink
Kim Gräsman added the comment:
Thanks for your response!
> I agree that send: and reply: should be formatted the same,
> so the reply: line should include the headers *with* the
> values.
OK, yeah, that would avoid having to specify request/response for headers as
well, I thin
New submission from Kim Gräsman:
Python 3.2.3 on 64-bit Windows 7.
When I set debuglevel on HTTPConnection to 1, the output seems jumbled, and I'm
having trouble interpreting it.
Attached is a full, anonymized log from a conversation I was troubleshooting.
Here's an excerpt:
send
23 matches
Mail list logo
