Warum verbinden rmdir und trennen zwei separate Systemaufrufe?


10

Hier ist etwas, das mich eine Weile gefragt hat:

[15:40:50][/tmp]$ mkdir a
[15:40:52][/tmp]$ strace rmdir a
execve("/usr/bin/rmdir", ["rmdir", "a"], [/* 78 vars */]) = 0
brk(0)                                  = 0x11bb000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff3772c3000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=245801, ...}) = 0
mmap(NULL, 245801, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff377286000
close(3)                                = 0
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\36\3428<\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=2100672, ...}) = 0
mmap(0x3c38e00000, 3924576, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3c38e00000
mprotect(0x3c38fb4000, 2097152, PROT_NONE) = 0
mmap(0x3c391b4000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b4000) = 0x3c391b4000
mmap(0x3c391ba000, 16992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3c391ba000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff377285000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff377283000
arch_prctl(ARCH_SET_FS, 0x7ff377283740) = 0
mprotect(0x609000, 4096, PROT_READ)     = 0
mprotect(0x3c391b4000, 16384, PROT_READ) = 0
mprotect(0x3c38c1f000, 4096, PROT_READ) = 0
munmap(0x7ff377286000, 245801)          = 0
brk(0)                                  = 0x11bb000
brk(0x11dc000)                          = 0x11dc000
brk(0)                                  = 0x11dc000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=106070960, ...}) = 0
mmap(NULL, 106070960, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff370d5a000
close(3)                                = 0
rmdir("a")                              = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++
[15:40:55][/tmp]$ touch a
[15:41:16][/tmp]$ strace rm a
execve("/usr/bin/rm", ["rm", "a"], [/* 78 vars */]) = 0
brk(0)                                  = 0xfa8000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3b2388a000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=245801, ...}) = 0
mmap(NULL, 245801, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3b2384d000
close(3)                                = 0
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\36\3428<\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=2100672, ...}) = 0
mmap(0x3c38e00000, 3924576, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3c38e00000
mprotect(0x3c38fb4000, 2097152, PROT_NONE) = 0
mmap(0x3c391b4000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b4000) = 0x3c391b4000
mmap(0x3c391ba000, 16992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3c391ba000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3b2384c000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3b2384a000
arch_prctl(ARCH_SET_FS, 0x7f3b2384a740) = 0
mprotect(0x60d000, 4096, PROT_READ)     = 0
mprotect(0x3c391b4000, 16384, PROT_READ) = 0
mprotect(0x3c38c1f000, 4096, PROT_READ) = 0
munmap(0x7f3b2384d000, 245801)          = 0
brk(0)                                  = 0xfa8000
brk(0xfc9000)                           = 0xfc9000
brk(0)                                  = 0xfc9000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=106070960, ...}) = 0
mmap(NULL, 106070960, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3b1d321000
close(3)                                = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
newfstatat(AT_FDCWD, "a", {st_mode=S_IFREG|0664, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
geteuid()                               = 1000
newfstatat(AT_FDCWD, "a", {st_mode=S_IFREG|0664, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
faccessat(AT_FDCWD, "a", W_OK)          = 0
unlinkat(AT_FDCWD, "a", 0)              = 0
lseek(0, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
close(0)                                = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

Warum gibt es separate Systemaufrufe zum Entfernen eines Verzeichnisses und von Dateien? Warum sollten diese beiden Operationen semantisch unterschiedlich sein?


Antworten:


9

Verzeichnisse sind insofern besonders, als Sie in einem Verzeichnis Verweise auf mehrere Dateien und Verzeichnisse haben können. Wenn Sie also das übergeordnete Verzeichnis entfernen, verlieren alle diese Dateien ihren Referenzpunkt, von dem aus auf sie zugegriffen werden kann, genau wie bei process. Führen Sie in solchen Fällen rmdir()unterschiedliche Prüfungen durch, die sich von folgenden unterscheiden unlink():

  • Wenn das Verzeichnis nicht leer ist. Wenn ein Verzeichnis nicht leer ist, kann es erst entfernt werden, wenn der Inhalt unlinkentfernt wurde.

       ENOTEMPTY
          pathname contains entries other than . and .. ; or, pathname has
          ..  as its final component.  POSIX.1-2001 also allows EEXIST for
          this condition.
    
  • Wenn das Verzeichnis verwendet wird. Wenn ein Prozess sein aktuelles Verzeichnis verliert, kann dies zu Problemen und undefiniertem Verhalten führen. Ist besser, sie zu verhindern.

       EBUSY  pathname  is currently in use by the system or some process that
          prevents its removal.  On Linux this means pathname is currently
          used  as  a  mount point or is the root directory of the calling
          process.
    

Bei unlink()diesen Prüfungen gibt es keine. Tatsächlich können Sie den Namen einer Datei mit löschen unlink()und der Prozess, der sie noch verwendet / auf sie verweist, kann sie problemlos ändern. Die Datei ist vorhanden, bis der Dateideskriptor vorhanden ist. Für einen neuen Prozess kann nur nicht zugegriffen werden (es sei denn, Sie wissen, wo Sie suchen müssen). Dies ist Teil der regenbogenfarbenen Handmagie der * NIX-Dateisysteme.

Nun gibt es das, unlinkat()was sich wie beides verhält unlink()oder rmdir(2)abhängig vom Pfad, den Sie erwarten.


Funktioniert gut rm -rf "$PWD"und entfernt das aktuelle Verzeichnis. Ich denke, der Grund, warum es a gibt, rmdir()ist wahrscheinlich historisch (anfangs waren die Verzeichnisse nicht verbunden () und rmdir (der Befehl) war die Verknüpfung von dir /., Dir / .. und dir, und als das in den Kernel verschoben wurde, musste das a sein neuer Systemaufruf, der alle 3 zumindest für eine Übergangszeit oder so etwas macht)
Stéphane Chazelas

@ StéphaneChazelas stimme zu, deshalb habe ich unlinkat hinzugefügt.
Braiam

Wenn ich Ihre Antwort richtig gelesen habe, sagen Sie, dass rmdir(dir)sie nicht funktioniert, wenn sie dirverwendet wird. Dies gilt zumindest nicht für Linux, wo es rmdir(getcwd())einwandfrei funktioniert (vorausgesetzt, das aktuelle Verzeichnis ist leer).
Stéphane Chazelas

@ StéphaneChazelas korrekt, von einem Prozess oder als Einhängepunkt verwendet: Der EBUSY Pfadname wird derzeit vom System oder einem Prozess verwendet, der das Entfernen verhindert . Unter Linux bedeutet dies, dass der Pfadname derzeit als Einhängepunkt verwendet wird oder das Stammverzeichnis des aufrufenden Prozesses ist.
Braiam

Ich bin nicht sicher, was sie unter oder ist das Stammverzeichnis des aufrufenden Prozesses . mkdir test; sudo strace -e chroot,rmdir perl -e 'chroot("test"); rmdir("test")'zeigt, dass sowohl chroot als auch rmdir erfolgreich sind.
Stéphane Chazelas
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.