in the core.
People tend to access functions of the posix module that are specific
to POSIX through the os module, but it isn't really meant this way.
But isn't that the way to write future-proof portable code? If one writes
code that calls os.symlink, and a future version of Python supports
Jason R. Coombs jar...@jaraco.com added the comment:
If I produce a patch for Python 3.1, can this capability possibly be
included in the release? Are there any objections to the implementation
as found in jaraco.windows?
--
___
Python tracker
Martin v. Löwis mar...@v.loewis.de added the comment:
With 3.1b1 already released, most likely this is too late for 3.1
(unless there would be a second beta, which is currently not planned).
--
___
Python tracker rep...@bugs.python.org
Benjamin Peterson benja...@python.org added the comment:
Fixed in r70650.
--
nosy: +benjamin.peterson
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5564
. This terminology is already in use
by os.rename.
--
assignee: georg.brandl
components: Documentation
messages: 84171
nosy: Rhamphoryncus, georg.brandl
severity: normal
status: open
title: os.symlink/os.link docs should say old/new, not src/dst
___
Python
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1578269
___
Changes by Antoine Pitrou pit...@free.fr:
--
versions: +Python 2.7, Python 3.1 -Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1578269
___
Hello,
From `pydoc os`:
symlink(...)
symlink(src, dst)
Create a symbolic link pointing to src named dst.
Is there any reason why this is so deliberately confusing? Why is the
target of the symlink, the think where it points *to*, called the
`src`? It seems to me
Nikolaus Rath wrote:
Hello,
From `pydoc os`:
symlink(...)
symlink(src, dst)
Create a symbolic link pointing to src named dst.
Is there any reason why this is so deliberately confusing? Why is the
target of the symlink, the think where it points *to*,
On 2008-07-28, Nikolaus Rath [EMAIL PROTECTED] wrote:
Hello,
From `pydoc os`:
symlink(...)
symlink(src, dst)
Create a symbolic link pointing to src named dst.
Is there any reason why this is so deliberately confusing? Why is the
target of the symlink, the
Georg Brandl added the comment:
Most of the os functions don't specify that they raise OSError in the
case of invalid or inaccessible paths.
I've now added a general note to that effect in r59930.
--
resolution: - fixed
status: open - closed
__
Tracker
David Gardner added the comment:
the output of symtest.py looks like:
type 'instance'
(13, 'Permission denied')
[Errno 13] Permission denied
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1809
__
New submission from David Gardner:
the docs for os.symlink at: http://docs.python.org/lib/os-file-dir.html
don't mention if the function raises an exception if there was a file
permission failure.
--
components: Documentation
files: symtest.py
messages: 59762
nosy: dgardner
severity
Sean Reifschneider added the comment:
swarren: According to the wikipedi article on junction points:
They can only be used on folders, not files.
They are being replaced by symbolic links.
The latter I take to mean junction points are being phased out, but I
couldn't find any information
Stephen Warren added the comment:
Hmm. I just tested Accurev - whatever it does, it works for files too.
That said, it could be making hard-links, which I guess could be different.
Additionally, the sysinternals junction utility doesn't find any
junction points when probing the link files.
Stephen Warren added the comment:
It seems that Accurev uses junction points for directories, and
hard-links for files. That's probably a little to disparate to implement
in Python?
Also, I tried sysinternals' junction.exe and whilst it allows one to
create junction points that point at files,
Sean Reifschneider added the comment:
If the file links are on the same volume, it's probably using hard
links. Symbolic links can cross file-systems, of course. So it sounds
like the Junction Points aren't going to work to replace symlinks, and
they'll be Vista only.
Stephen Warren added the comment:
I'd say that junction points were a great way to expose this feature
under Win32 - after all, isn't it specifically what they were designed for?
Incidentally, at least one other application uses them for exactly this
purpose; a commercial source control tool
() and os.symlink() support for Windows
Initial Comment:
NTFS version 5.0 and up has all the needed APIs for
creating hard links and symlinks (junctions), so it
should be possible to add support for both hard links
and symlinks to the posixmodule.
Here are a few references:
http://schinagl.priv.at/nt
of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add os.link() and os.symlink
() and os.symlink() support for Windows
Initial Comment:
NTFS version 5.0 and up has all the needed APIs for
creating hard links and symlinks (junctions), so it
should be possible to add support for both hard links
and symlinks to the posixmodule.
Here are a few references:
http://schinagl.priv.at
301 - 321 of 321 matches
Mail list logo
