Voici quelque chose qui m'a fait réfléchir pendant un moment:
[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 +++
Pourquoi y a-t-il des appels système distincts pour supprimer un répertoire et des fichiers? Pourquoi ces deux opérations seraient-elles sémantiquement distinctes?
linux
directory
rm
system-calls
d33tah
la source
la source
Réponses:
Les répertoires sont spéciaux dans le sens où, dans un répertoire, vous pouvez avoir des références à plusieurs fichiers et répertoires.Par conséquent, si vous supprimez le répertoire parent, tous ces fichiers perdent leur point de référence d'où ils peuvent être consultés, de même avec le processus. Pour de tels cas,
rmdir()
ayez des contrôles différents, différents deunlink()
:Si le répertoire n'est pas vide. Si un répertoire n'est pas vide, il ne peut pas le supprimer tant que le contenu n'est
unlink
pas supprimé.Si le répertoire est en cours d'utilisation. Si un processus perd son répertoire actuel, cela peut entraîner des problèmes et des comportements indéfinis. Mieux vaut les empêcher.
Dans le cas de
unlink()
ces contrôles n'existe pas. En fait, vous pouvez supprimer le nom d'un fichier avecunlink()
et le processus qui utilise / fait toujours référence à lui, peut le modifier sans problème. Le fichier existe jusqu'à ce que le descripteur de fichier existe, tout simplement inaccessible au nouveau processus (sauf si vous savez où chercher). Cela fait partie de la magie des mains aux couleurs arc-en-ciel des systèmes de fichiers * NIX.Maintenant, il y a le
unlinkat()
qui se comporte comme les deux,unlink()
ourmdir(2)
selon le chemin qui est ce que vous attendez.la source
rm -rf "$PWD"
et supprime le répertoire actuel. Je pense que la raison pour laquelle il y armdir()
est probablement historique (au départ, les répertoires étaient dissociés () et rmdir (la commande) dissociait dir /., Dir / .. et dir, et quand cela a été déplacé vers le noyau, cela devait être un nouveau syscall faisant les 3 au moins pendant une période de transition ou quelque chose comme ça)rmdir(dir)
cela ne fonctionne pas s'ildir
est utilisé. Ce n'est pas vrai sur Linux au moins, où celarmdir(getcwd())
fonctionne très bien (à condition que le répertoire actuel soit vide).EBUSY
chemin d'accès est actuellement utilisé par le système ou un processus qui empêche sa suppression . Sous Linux, cela signifie que le chemin d'accès est actuellement utilisé comme point de montage ou est le répertoire racine du processus appelant.mkdir test; sudo strace -e chroot,rmdir perl -e 'chroot("test"); rmdir("test")'
montre que chroot et rmdir réussissent.