Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I cannot reproduce the behavior that your trace suggests; instead, I get
>>> os.remove("foo") Traceback (most recent call last): File "<stdin>", line 1, in ? OSError: [Errno 1] Not owner: 'foo' Perhaps you were trying to do this as root? This is a known issue with Solaris: it allows to call unlink(2) for directories. This is documented in unlink(2) as If the path argument is a directory and the filesystem sup- ports unlink() and unlinkat() on directories, the directory is unlinked from its parent with no cleanup being performed. In UFS, the disconnected directory will be found the next time the filesystem is checked with fsck(1M). The unlink() and unlinkat() functions will not fail simply because a directory is not empty. The user with appropriate privileges can orphan a non-empty directory without generating an error message. If the path argument is a directory and the filesystem does not support unlink() and unlink() on directories (for exam- ple, ZFS), the call will fail with errno set to EPERM. As os.remove is the same as unlink, and as os.unlink deliberately calls the system call, this is not a bug in Python. Closing it as "won't fix, 3rd party". ---------- nosy: +loewis resolution: -> wont fix status: open -> closed versions: +3rd party _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4210> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com