This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients giampaolo.rodola, loewis
Date 2008-10-26.18:49:57
SpamBayes Score 1.1932937e-09
Marked as misclassified No
Message-id <1225047006.9.0.996031122645.issue4210@psf.upfronthosting.co.za>
In-reply-to
Content
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".
History
Date User Action Args
2008-10-26 18:50:07loewissetrecipients: + loewis, giampaolo.rodola
2008-10-26 18:50:06loewissetmessageid: <1225047006.9.0.996031122645.issue4210@psf.upfronthosting.co.za>
2008-10-26 18:49:58loewislinkissue4210 messages
2008-10-26 18:49:57loewiscreate