bugThe GNU Hurd - Bugs: bug #28859, remove(3) fails to remove an empty...

 
 

bug #28859: remove(3) fails to remove an empty directory

Submitter:  Ludovic Courtès <civodul>
Submitted:  Wed 10 Feb 2010 04:28:07 PM UTC
   
 
Category:  glibc Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  tschwinge Originator Name:  Ludovic Courtès
Open/Closed:  Closed Reproducibility:  None
Size (loc):  None Planned Release:  None
Effort:  0.00
Wiki-like text discussion box: 


* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 04 Apr 2010 06:45:16 PM UTC, comment #5: 

Fixed upstream in cb652f30b0aa17e65803962305e052e509a5316d.

Thomas Schwinge <tschwinge>
Group administrator
Fri 26 Feb 2010 08:28:43 AM UTC, comment #4: 

Yes, I'll commit the fix there, as soon (``soon'' -- pun unavoidable...) as I get back to working on glibc.

Thomas Schwinge <tschwinge>
Group administrator
Tue 23 Feb 2010 04:40:12 PM UTC, comment #3: 

For now, how about fixing it locally in hurd/glibc.git at Savannah?

Ludovic Courtès <civodul>
Group Member
Fri 12 Feb 2010 09:53:30 AM UTC, comment #2: 

I forwarded the bug to glibc's bug tracker: http://sources.redhat.com/bugzilla/show_bug.cgi?id=11276 .

Ludovic Courtès <civodul>
Group Member
Wed 10 Feb 2010 04:43:17 PM UTC, comment #1: 

Your analysis is correct, see here: <http://lists.gnu.org/archive/html/bug-hurd/2009-11/msg00238.html>

You could forward the appropriate patch and reasoning to libc-alpha, otherwise I'll do it as soon as I get back to working on Hurd's glibc stuff.

Thomas Schwinge <tschwinge>
Group administrator
Wed 10 Feb 2010 04:28:07 PM UTC, original submission:  

Hello,

The remove(3) libc function fails to remove an empty directory.

Consider this program:

#v+
#include <stdio.h>
#include <error.h>
#include <errno.h>

int
main (int argc, char *argv[])
{
  if (remove (argv[1]))
    error (1, errno, "failed");

  return 0;
}
#v-

Here's a comparison of Coreutils' `rm' and this program:

#v+
ludo@goober:~$ mkdir chbouib
ludo@goober:~$ rpctrace -o remove.log ./remove chbouib
./remove: failed: Operation not permitted
ludo@goober:~$ rpctrace -o rmdir.log rmdir chbouib
ludo@goober:~$ grep -C3 chbouib {remove,rmdir}.log
remove.log-task15378->vm_allocate (17147851 4096 1) = 0 16941056
remove.log-task15378->vm_deallocate (16936960 16) = 0
remove.log-task15378->mach_port_mod_refs (pn{  8} 0 1) = 0
remove.log:  56->dir_unlink ("chbouib") = 0x40000001 (Operation not permitted)
remove.log-task15378->mach_port_deallocate (pn{  8}) = 0
remove.log-  54->io_write_request ("./remove: " -1) = 0 10
remove.log-  54->io_write_request ("failed" -1) = 0 6
--
rmdir.log-task15343->vm_allocate (17147851 4096 1) = 0 16941056
rmdir.log-task15343->vm_deallocate (16936960 16) = 0
rmdir.log-task15343->mach_port_mod_refs (pn{  8} 0 1) = 0
rmdir.log:  56->dir_rmdir ("chbouib") = 0
rmdir.log-task15343->mach_port_deallocate (pn{  8}) = 0
rmdir.log-task15343->mach_port_deallocate (pn{  5}) = 0
rmdir.log-task15343->mach_port_deallocate (pn{  6}) = 0
#v-

My guess is that this is a problem in glibc:

#v+
int
remove (file)
     const char *file;
{
  /* First try to unlink since this is more frequently the necessary action. */
  if (__unlink (file) != 0
      /* If it is indeed a directory...  */
      && (errno != EISDIR
  /* ...try to remove it.  */
  || __rmdir (file) != 0))
    /* Cannot remove the object for whatever reason.  */
    return -1;

  return 0;
}
#v-

Here glibc should be prepared to deal with `EPERM', which is the suitable error code for this case according to POSIX 2008.  The "Rationale" section at http://www.opengroup.org/onlinepubs/9699919799/functions/unlink.html says that "[aA]pplications written for portability to both POSIX.1-2008 and the LSB should be prepared to handle either error code."  Thus I think the right fix is to have glibc's remove(3) handle both `EISDIR' and `EPERM', regardless of the underlying kernel.

What do you think?

Thanks,
Ludo'.

Ludovic Courtès <civodul>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by tschwinge (Posted a comment)
  • -email is unavailable- added by civodul (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-04-04 tschwinge StatusNone Fixed
        Open/ClosedOpen Closed
    2010-02-26 tschwinge Assigned toNone tschwinge
    2010-02-10 tschwinge CategoryHurd Servers glibc

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code