[issue9333] Expose a way to enable os.symlink on Windows

Brian Curtin added the comment: Oops, sorry. Fixed in r87561. -- stage: commit review -> committed/rejected status: open -> closed ___ Python tracker ___

[issue9333] Expose a way to enable os.symlink on Windows

Amaury Forgeot d'Arc added the comment: Tests now fail on windows XP: http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/3874/steps/test/logs/stdio os.symlink() may raise NotImplementedError, and test.support.can_symlink() should catch it. -- stage: committed/reje

[issue9333] Expose a way to enable os.symlink on Windows

Brian Curtin added the comment: Checked in a small doc update in r87547. Removes the part about os.symlink not being available, and mentions the OSError. -- ___ Python tracker _

[issue9333] Expose a way to enable os.symlink on Windows

Brian Curtin added the comment: Thanks for having a look. Checked in with the suggested changes to r87539. -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed ___ Python tracker

[issue9333] Expose a way to enable os.symlink on Windows

Amaury Forgeot d'Arc added the comment: The patch looks good, I only have stylistic remarks: - We normally don't use windows-specific types in CPython code. Please use int instead of BOOL. And C variables are usually lowercase, even module globals. I suggest something like "static int win32_ca

[issue9333] Expose a way to enable os.symlink on Windows

Brian Curtin added the comment: (hit enter too soon, sorry) The patch makes os.symlink always available on Windows machines, but it will only have an effect when privileged. Windows XP and Windows 2003 will still receive NotImplementedError, as the underlying calls aren't available there. On

[issue9333] Expose a way to enable os.symlink on Windows

Brian Curtin added the comment: Here's a patch. I think this works more like what you guys are looking for. Tests pass on Windows 7 and I checked it on a Mac to be sure, and it's good there too. -- Added file: http://bugs.python.org/file20178/issue9333_v3.diff ___

[issue9333] Expose a way to enable os.symlink on Windows

Brian Curtin added the comment: I'll come up with a patch to make the attribute always available, but raise OSError when the privilege is not held. -- resolution: fixed -> ___ Python tracker _

[issue9333] Expose a way to enable os.symlink on Windows

Jason R. Coombs added the comment: Thanks and good work, Brian. I think ,though, I'm leaning toward agreeing with Amaury on the presence of the symlink attribute in os. I can easily see the justification for hiding it in legacy environments (Windows XP & Server 2003), where the relevance dim

[issue9333] Expose a way to enable os.symlink on Windows

Brian Curtin added the comment: > So the presence of os.symlink depends on some dynamic privilege? Yes. > Why not simply raise an exception when the user has not enough > privileges? (I mean OSError or WindowsError of course, not AttributeError) My thinking was that anyone writing cross-plat

[issue9333] Expose a way to enable os.symlink on Windows

Amaury Forgeot d'Arc added the comment: So the presence of os.symlink depends on some dynamic privilege? It seems to me that it's the first time in Python. For example, os.chroot() is always available on Unix, even when the user is not root. Of course the call will fail at runtime. Why not

[issue9333] Expose a way to enable os.symlink on Windows

Brian Curtin added the comment: Fixed in r86935. Tests pass on the following setups: - Windows 7 (regular user - no symlink privilege) - Windows 7 (administrator + symlink privilege) - Windows Server 2003 (no symlink abilities) - Arch Linux (just a sanity check) I'm going to create a follow-up

[issue9333] Expose a way to enable os.symlink on Windows

Brian Curtin added the comment: I've tried changing privileges for a user and I'm not seeing that they get reflected in real-time while an application is running. Maybe I'm not doing it right, but I'm not seeing it. I'm also not able to find anything about that being supported or anyone else

[issue9333] Expose a way to enable os.symlink on Windows

Brian Curtin added the comment: I'll have to investigate the possibility of the privilege occurring on XP -- I'm doubtful that it exists there, but I'll confirm. Currently "os._symlink" is not exposed -- it gets swallowed up in Lib/os.py in the "nt" section starting on line 55 (it is availabl

[issue9333] Expose a way to enable os.symlink on Windows

Jason R. Coombs added the comment: I love it -- especially all of the '-' lines in the patch! Good work. Is it conceivable that a Windows XP user would have that privilege (and thus would have access to a non-functional os.symlink function)? One thing I particularly like is this provides an i

[issue9333] Expose a way to enable os.symlink on Windows

Brian Curtin added the comment: Forgot to mention: I've only run this on Win7 at the moment. I'll need to take a look at how this works on older Windows. -- ___ Python tracker _

[issue9333] Expose a way to enable os.symlink on Windows

Brian Curtin added the comment: Here's a patch implementing a similar idea to what Jason mentioned, complete with the test updates and code removals. It initially adds win_symlink as "_symlink", and on module initialization it will be renamed to "symlink" if the privilege is available. There

[issue9333] Expose a way to enable os.symlink on Windows

Changes by Brian Curtin : Removed file: http://bugs.python.org/file18132/enable_symlink.diff ___ Python tracker ___ ___ Python-bugs-list mailin

[issue9333] Expose a way to enable os.symlink on Windows

Jason R. Coombs added the comment: I'm attaching this patch for discussion: Here's what I had in mind for addressing the NotImplementedError when calling os.symlink on Windows XP. During the posixmodule initialization, if the system does not have the CreateSymbolicLink API call, the function

[issue9333] Expose a way to enable os.symlink on Windows

Jason R. Coombs added the comment: I'm not sure the setting has to be restored. All that's being added is an attempt to assign the symlink privilege to the current process token. I would consider to attempt to assign the privilege when the Python process starts up (or when os is loaded) - and

[issue9333] Expose a way to enable os.symlink on Windows

Eric Smith added the comment: Wouldn't you have to set this, then restore it? This would then open a non thread-safe race condition, assuming this is a per-process setting, not a thread-local setting. Not that I'm necessarily opposed, but it's an issue. -- __

[issue9333] Expose a way to enable os.symlink on Windows

Brian Curtin added the comment: That's a way better idea. It would also cut down some of the code in Lib/test/symlink_support.py. I'll take a whack at that and see how it looks. -- ___ Python tracker _

[issue9333] Expose a way to enable os.symlink on Windows

Jason R. Coombs added the comment: I think we should consider simply calling this function before running os.symlink. It would be nice if the API were as compatible as possible on both unix and Windows. My worry is that where code that works on unix systems is simply: os.symlink(...) Bu

[issue9333] Expose a way to enable os.symlink on Windows

New submission from Brian Curtin : As it currently stands, the possibility exists that some users might not have the SeCreateSymbolicLinkPrivilege privilege enabled (depending on security settings, corporate policy, etc). There should be some method of enabling that privilege outside of the wa