-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
os.removedirs()
should define whether it follows symlinks
#134161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I'm afraid that symbolic links were not taken into account when these functions were written. There is no design behind The current behavior is just an artifact of implementation. It can be changed if we approach their design thoughtfully. But now they are simply neglected. |
@serhiy-storchaka Would it be better to document the functionality as it's currently implemented? If not, would it be better than nothing to add what you described above to the docs, i.e., there is no design behavior? I'd be willing to put up an initial PR to get either started. |
What exactly do you mean by that? @ryan-duve IMO, proper documentation would suffice for now, and a future version could add options whether or nor not follow symlinks (and perhaps even which), should that be needed. AFAICS, right now it won't follow any symlinks. That is, in
IMO that's all quite reasonable and should be even the default, if Cheers, |
|
Ah, I see what you mean. I have only had a brief glance over the code, but from what I saw, it would always try to delete the full given pathname, that is if you give it So I'd say the behaviour is well-defined (and reasonable), the only problem is that you cannot easily remove empty-dir hierarchies that are outside of your current directory. Of course you can do a Perhaps a future update of |
Documentation
Many functions in
os
do not properly specify whether or not they follow symlinks. The Files and Directories even slightly implies that the default is more to follow symlinks (and only withfollow_symlinks=False
not).For some functions (like
os.rmdir()
one might argue this is not important because they're the counterparts of well-known POSIX/C functions and for them it's well-defined.But e.g.
os.removedirs()
seem to have no such counterpart and since the documentation doesn't mention anything, the current behaviour (which AFAICS is not following symlinks) might just be some implementation detail.For
os.removedirs()
there are even two interesting cases in e.g.os.removedirs("a/b/c/d")
:d
(i.e. the final pathname component) is a symlink to a directory the referred directory is not removed (at least not in the current code, which usesos.rmdir()
on the pathname)b
is a symlink to a directory, which contains onlyc/d
, thenb
is followed whenrmdir
inga/b/c/d
anda/b/c
but is not followed whenrmdir
inga/b
(and the target ofb
isn’t removed).All this kinda follows the spirit of POSIX' pathname resolution, but still it would IMO be nice to have it clearly defined.
Cheers,
Chris.
The text was updated successfully, but these errors were encountered: