Même dossier et nom de fichier au même emplacement

15

Dans Ubuntu, pourquoi ne puis-je pas avoir un dossier nommé "MyFile" et un document nommé "MyFile" au même endroit? J'ai une item already used in this locationerreur. Ubuntu / Linux traite-t-il les dossiers et fichiers comme les mêmes objets (pointeurs vers le disque)?

pebox11
la source
Est-il nommé exactement comme ça? Le fichier a-t-il un premier point dans le nom de fichier? Par exemple .myfile,?
Sergiy Kolodyazhnyy
J'ai eu le même problème. J'en ai renommé un. Il existe plusieurs options: renommer le dossier en minuscules ou ajouter une extension, par exemple - monfichier ou Mon.Fichier. Ou renommez le fichier en MyFile.txt. Renommer l'un ou l'autre fonctionnera aussi bien.
Buck
3
Duplication de Pourquoi ne puis-je pas avoir un dossier et un fichier du même nom?   (sous Unix et Linux)
G-Man dit 'Reinstate Monica'
Je partage votre frustration. Je crée un site Web statique et je ne peux pas avoir de version locale blogcontenant un dossier appelé avec des articles de blog et une page html appelée blogavec une liste d'articles de blog.
Costa

Réponses:

29

Sous Linux, presque tout est un descripteur de fichier. Un répertoire est un type spécial de fichier qui, du point de vue de l'utilisateur, peut contenir d'autres fichiers.

Vous ne pouvez donc pas avoir les deux avec le même nom, dans le même répertoire en même temps.

Si vous le pouviez, la vie deviendrait misérable pour les codeurs. Que voudriez-vous que la commande "isDir" renvoie lorsque quelqu'un veut créer un répertoire et vérifier qu'il existe. IsDir ("/ home / shrodingers / cat") doit-il renvoyer true, false ou les deux? Et à quoi vous attendriez-vous si quelqu'un veut ouvrir un répertoire d'un fichier dans du code?

Et que doit faire le système lorsque vous lui dites d'ouvrir quelque chose? Supposons que vous vouliez le fichier? Cela signifie des ennuis ;)

Soit dit en passant: cela est vrai pour TOUS les systèmes d'exploitation, pas seulement Linux. Bien que du point de vue du bureau, un système d'exploitation puisse ajouter un identifiant unique au fichier ou au répertoire et le supprimer de la liste. Du point de vue de la ligne de commande, ce serait problématique.

Il y a une chose que nous avons sur Windows: nous utilisons des noms sensibles à la casse. Donc "MYFILE" et "myfile" sont des choses différentes.

Rinzwind
la source
2
Pas de problème :) Je le fais pour les votes positifs ;-)
Rinzwind
1
@Rinzwind pour les votes positifs? Ok, voici un autre
AB
1
La théorie Linux de tout: tout est fichier!
Byte Commander
Anthon et moi avons collaboré à la blague chat / les deux de Schrödinger il y a quatre mois . Et, comme le dit Byte Commander, l'expression est "Tout est un fichier", pas "tout est un descripteur de fichier".
G-Man dit `` Réintègre Monica ''
1
Plan9 ( plan9.bell-labs.com/plan9 ) (créateurs originaux d'Unix) est probablement le seul OS où "tout est un fichier". Pour tous les autres systèmes Unix et Linux, la phrase correcte est "tout est un descripteur de fichier". "Tout est un fichier" sauf la mémoire, les appels système, les périphériques réseau et à peu près tout sauf les fichiers MAIS ils ont tous un descripteur de fichier ;-) Au cas où quelqu'un voudrait continuer avec ça -> chat: =)
Rinzwind
1

vous ne pouvez pas avoir deux entités portant le même nom au même emplacement. que se passera-t-il lorsque vous voudrez cat ou vi le fichier? quelle entité l'OS choisira-t-il? ainsi, en raison de la possibilité de confusion, vous ne pourrez pas avoir le même nom pour un fichier et un dossier au même emplacement. et par la façon dont un dossier est un fichier qui héberge d'autres fichiers.

L. Barzic
la source
3
Votre réponse lui renvoie la question du PO ("vous ne pouvez pas avoir deux entités avec le même nom au même endroit", ce qu'il sait clairement déjà - la question est "pourquoi?"), Puis vous posez des questions rhétoriques , comme si elles étaient sans réponse, et cela a résolu la question. Si j'ai un fichier et un répertoire du même nom, et moi catou vice nom, alors, évidemment, le système d'exploitation devrait choisir le fichier. Pourquoi ça ne marche pas?
G-Man dit `` Réintègre Monica ''
2
@ G-Man: en fait, vice qui est généralement vimsur Ubuntu est parfaitement heureux d'ouvrir et d'afficher un répertoire et même de le modifier. Essayez-le: vi .
arielf
1
@arielf: (1) Je disais que, s'il était possible qu'un fichier et un sous-répertoire du même nom existent dans le même répertoire, alors lorsqu'une commande (principalement) orientée fichier telle que catou viest adressée à ce nom , l' interprétation logique consiste à l'invoquer dans le fichier plutôt que dans le sous-répertoire. Le fait qu'une commande (principalement) orientée fichier ( vi) fonctionne également sur un (sous-) répertoire n'est pas pertinent pour cette instruction.
G-Man dit `` Réintègre Monica ''
1
(2) Votre déclaration est un hareng rouge. vimne traite pas les arguments des sous-répertoires avec naïveté; avec le même code avec lequel il gère les fichiers.  vimsemble être (à un niveau très simpliste) deux programmes en un: s'il est invoqué sur un fichier, il agit comme un éditeur de texte, et s'il est invoqué sur un sous-répertoire, il agit comme un gestionnaire de fichiers.
G-Man dit `` Réintègre Monica ''
1
@ G-Man: Je faisais seulement référence à votre dernière affirmation dans le 1er commentaire: "alors, évidemment, l'OS devrait choisir le fichier." - c'est ce qui m'a sauté aux yeux comme non vrai vi. À votre santé.
arielf
1

Je sais que c'est un vieux sujet, mais je viens d'avoir le même problème et je voulais partager.
Voici mon histoire (soyez patient, il y a une fin heureuse).

Environnement:
noyau Gentoo 4.12.5 64bits sur reiserfs

Comment cela a-t-il pu arriver?
J'ai plusieurs machines avec un dossier partagé en utilisant la synchronisation. À un certain moment dans le passé, j'ai supprimé un fichier nommé ".stfolder" et créé un répertoire avec ce nom à la place. Alors peut-être que le bogue est dû à la synchronisation de la synchronisation de cette opération sur une autre machine.

Examinons maintenant le bug: (j'opère en tant que root ici)

ls -lahd .*
drwxrwx--- 5 stopi syncthing 656  3 sept. 18:24 .
drwxr-xr-x 5 stopi stopi     240  3 sept. 18:21 ..
drw-rw---- 2 stopi syncthing  48  3 sept. 18:24 .stfolder
-rw-rw---- 1 stopi syncthing   0 29 août  12:51 .stfolder
-rw-rw---- 1 stopi syncthing  23 28 oct.   2017 .stignore

find -type f -name .stfolder
                              (<= no output there)

find -type f -name ".*"
./.stignore
./.stfolder

find -type f -name ".s*"
./.stignore

ressemble au fichier est un fantôme mais le dossier répond normalement (avec find)

file .*
.:             directory
..:            directory
.stfolder:     directory
.stfolder:     empty
.stignore:     C source, ASCII text

file .s*
.stfolder:     directory
.stignore:     C source, ASCII text

Je sais, très bizarre ...

rm -r .stfolder

ls -lahd .*
drwxrwx--- 5 stopi syncthing 656  3 sept. 18:24 .
drwxr-xr-x 5 stopi stopi     240  3 sept. 18:21 ..
-rw-rw---- 1 stopi syncthing   0 29 août  12:51 .stfolder
-rw-rw---- 1 stopi syncthing  23 28 oct.   2017 .stignore

rm .stfolder
rm: impossible de supprimer '.stfolder': Aucun fichier ou dossier de ce type

Je ne peux pas supprimer ce fichier fantôme!

Mais à la fin, je l'ai supprimé avec succès en le déplaçant sur un point de montage tmpfs

mv .stfolder /elsewhere/
mv: impossible d'évaluer '.stfolder': Aucun fichier ou dossier de ce type
mv .* /elsewhere/

Je dois dire que le bug est toujours présent sur tmpfs, donc pas lié à reiserfs:

cd /elsewhere

ls -lahd .*
-rw-rw----  1 stopi syncthing   0 29 août  12:51 .stfolder

ls -lahd .s*
ls: impossible d'accéder à '.s*': Aucun fichier ou dossier de ce type

Comme vous pouvez le voir dans cette sortie bash, le fichier est présent et non présent en même temps. En raison de cette capacité de chat Schrödinger , nous pouvons créer un dossier avec le même nom.
Mais attendez, il y a plus (et vous devriez trouver cela évident): nous pouvons également créer un autre fichier avec le même nom.

touch .stfolder

ls -lahdQ
total 0
drwxrwxr-x  3 root   users  100  3 sept. 19:13 "."
drwxrwxrwt 18 root   root   440  3 sept. 17:35 ".."
-rw-r--r--  1 root   root     0  3 sept. 19:13 ".stfolder"
-rw-r-----  1 root   root     0  3 sept. 19:09 ".stfolder"

Le fantôme peut être copié (donc je peux dupliquer le bogue), ou manipulé par chown, chmod, etc. la seule restriction est que vous ne pouvez pas le nommer donc vous devez le mettre dans un répertoire vide et utiliser ". *" Comme arguments pour ces commandes ... mais ça marche!

En raison de sa nature même, ce fichier était vide depuis le début (c'est juste un indicateur de synchronisation).
J'étais donc curieux de pouvoir mettre des données dans ce fichier.
Et ici, la solution m'est venue:

vi .*
" ============================================================================
" Netrw Directory Listing                                        (netrw v162)
"   /elsewhere
"   Sorted by      name
"   Sort sequence: [\/]$,\<core\%(\.\d\+\)\=\>,\.h$,\.c$,\.cpp$,\~\=\*$,*,\.o$,\.obj$,\.info$,\.swp$,\.bak$,\~$
"   Quick Help: <F1>:help  -:go up dir  D:delete  R:rename  s:sort-by  x:special
" ==============================================================================
../
./
.<200b>stfolder

Oui, il y a un caractère invisible dans ce fichier, juste après le point.
Cela explique tout.
Dieu merci, je n'ai pas utilisé "test d'écho >>. *" Et chat ...

Stopi
la source
U+200best un "espace de largeur nulle" , soit dit en passant. J'aime cette anecdote, même si je crains qu'elle ne soit pas entièrement considérée comme une réponse.
PerlDuck
0

/unix//a/238056/139805

wow c'est vraiment bizarre mais je viens de faire ce que l'auteur a demandé. Voici comment, c'est donc une vraie réponse: P

charles@charles-MacBook ~ $ cd /usr/share
charles@charles-MacBook /usr/share $ ls -ld pix*
drwxr-xr-x 13 root root  4096 Oct 22 21:04 pixmaps
-rw-r--r--  1 root root 17626 Oct 22 21:07 pixmaps 
charles@charles-MacBook /usr/share $ mv pixmaps pixmaps
mv: cannot move ‘pixmaps’ to a subdirectory of itself, ‘pixmaps/pixmaps’
charles@charles-MacBook /usr/share $ ls -ld pix*
drwxr-xr-x 13 root root  4096 Oct 22 21:04 pixmaps
-rw-r--r--  1 root root 17626 Oct 22 21:07 pixmaps 
charles@charles-MacBook /usr/share $ file pix*
pixmaps:  directory
pixmaps : X pixmap image, ASCII text

cela a été fait par:

charles-MacBook MaSSH # ls
instMaSSH.sh  MaSSHandra  MaSSHandra.desktop  MaSSHandraMesh.xpm
MaSSHandra.xpm  mime-MaSSHandra.xml
charles-MacBook MaSSH # cat instMaSSH.sh 
cp -i MaSSHandra.desktop /usr/share/applications
cp -i MaSSHandra.xpm /usr/share/pixmaps 
cp -i MaSSHandraMesh.xpm /usr/share/pixmaps
xdg-icon-resource install --context mimetypes --size 48 /usr/share/pixmaps/MaSSHandra.xpm application-x-MaSSHandra
xdg-icon-resource install --context mimetypes --size 48 /usr/share/pixmaps/MaSSHandraMesh.xpm application-x-MaSSHandraMesh
setcap cap_net_raw+ep /opt/MaSSHandra/bin/MaSSHandra
charles-MacBook MaSSH # ./instMaSSH.sh 
cp: overwrite ‘/usr/share/applications/MaSSHandra.desktop’? y
xdg-icon-resource: file '/usr/share/pixmaps/MaSSHandra.xpm' does not exist
xdg-icon-resource: file '/usr/share/pixmaps/MaSSHandraMesh.xpm' does not exist

whoah alternent deux fichiers avec le même nom, même plus un répertoire et un fichier ce qui se passe ??? _

charles-MacBook share # ls -ld pi*
drwxr-xr-x 13 root root  4096 Oct 22 21:08 pixmaps
-rw-r--r--  1 root root 17626 Oct 22 21:09 pixmaps 
charles-MacBook share # mv pixmaps /tmp
charles-MacBook share # mv pixmaps  /tmp/pixmaps/
charles-MacBook share # ls -ld pix*
-rw-r--r-- 1 root root 21535 Oct 22 21:26 pixmaps
-rw-r--r-- 1 root root 17626 Oct 22 21:26 pixmaps 
charles-MacBook share # ls -li pix*
1849351 -rw-r--r-- 1 root root 21535 Oct 22 21:26 pixmaps
1841386 -rw-r--r-- 1 root root 17626 Oct 22 21:26 pixmaps 
charles-MacBook share # file pix*
pixmaps:  X pixmap image, ASCII text
pixmaps : X pixmap image, ASCII text
charles-MacBook share # ls -liF pix*
1849351 -rw-r--r-- 1 root root 21535 Oct 22 21:26 pixmaps
1841386 -rw-r--r-- 1 root root 17626 Oct 22 21:26 pixmaps 

comportement totalement étrange

charles-MacBook MaSSH # ls -l /usr/share/pixmaps
pixmaps   pixmaps   
charles-MacBook MaSSH # rm -i /usr/share/pixmaps                                                                 
rm: remove regular file ‘/usr/share/pixmaps’? y
charles-MacBook MaSSH # ls -l /usr/share/pixmaps  
-rw-r--r-- 1 root root 17626 Oct 22 21:26 /usr/share/pixmaps 
charles-MacBook MaSSH # rm -i /usr/share/pixmaps
rm: cannot remove ‘/usr/share/pixmaps’: No such file or directory
charles-MacBook MaSSH # ls -l /usr/share/pixmaps  
-rw-r--r-- 1 root root 17626 Oct 22 21:26 /usr/share/pixmaps 
charles-MacBook MaSSH # cd /usr/share
charles-MacBook share # rm pixmaps  
charles-MacBook share # 
Charles Adrian Posinoff
la source
2
L'un des deux noms a une forme d'espace à la fin. Vous pouvez le voir dans les sorties "fichier".
dascandy