You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Pathlib .owner() and .group() methods fail on broken links #65521
Most other Path methods operate on the link target, not the link itself, so I don't see why these methods would work otherwise.
inigoserna commented on Apr 22, 2014
inigosernamannequin
MannequinAuthor
More actions
Mainly, 2 reasons:
It can make programs crash *unexpectedly*
Pathlib should provide a complete and uniform API for dealing with all types of files. If not, users would need to use Pathlib for some kind of files and go to os and os.path for others, then why the reason to use Pathlib?
A broken link is an error, so it's normal to have an exception raised
here. An exception can always be caught if you were expecting the error.
Pathlib should provide a complete and uniform API for dealing with
all types of files. If not, users would need to use Pathlib for some
kind of files and go to os and os.path for others, then why the reason
to use Pathlib?
I sympathize with this. But you can already use Path.lstat() and inspect
the st_uid and st_gid fields if you are really interested in the link's
owner and group (rather than the target's).
The fact that most Path methods dereference symlinks reflects the
semantics of other common filesystem calls (such as those in the os
module, or the underlying functions of the POSIX API).
Activity
inigoserna commentedon Apr 21, 2014
Pathlib .owner() and .group() methods fail on broken symlinks.
They use:
return pwd.getpwuid(self.stat().st_uid).pw_name
and:
return grp.getgrgid(self.stat().st_gid).gr_name
It should be self.lstat().
Attached simple fix as unified diff.
pitrou commentedon Apr 21, 2014
Most other Path methods operate on the link target, not the link itself, so I don't see why these methods would work otherwise.
inigoserna commentedon Apr 22, 2014
Mainly, 2 reasons:
It can make programs crash *unexpectedly*
Pathlib should provide a complete and uniform API for dealing with all types of files. If not, users would need to use Pathlib for some kind of files and go to os and os.path for others, then why the reason to use Pathlib?
pitrou commentedon Apr 22, 2014
A broken link is an error, so it's normal to have an exception raised
here. An exception can always be caught if you were expecting the error.
I sympathize with this. But you can already use Path.lstat() and inspect
the st_uid and st_gid fields if you are really interested in the link's
owner and group (rather than the target's).
The fact that most Path methods dereference symlinks reflects the
semantics of other common filesystem calls (such as those in the os
module, or the underlying functions of the POSIX API).