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 ...
.myfile,?