Ten sam folder i nazwa pliku w tej samej lokalizacji

15

Dlaczego w Ubuntu nie mogę mieć folderu o nazwie „MyFile” i dokumentu o nazwie „MyFile” w tej samej lokalizacji? Dostaję item already used in this locationbłąd Czy Ubuntu / Linux traktuje foldery i pliki jako te same obiekty (wskaźniki na dysk)?

pebox 11
źródło
Czy to tak się nazywa? Czy plik ma wiodącą kropkę w nazwie pliku? Na przykład .myfile?
Sergiy Kolodyazhnyy
Miałem ten sam problem. Zmieniłem nazwę jednego. Istnieje kilka opcji: Zmień nazwę folderu na małe litery lub dodaj rozszerzenie, na przykład - mój_plik lub Mój.plik. Lub zmień nazwę pliku na MyFile.txt. Zmiana nazwy jednego z nich będzie działać równie dobrze.
Buck
3
Duplikat Dlaczego nie mogę mieć folderu i pliku o tej samej nazwie?   (w systemach Unix i Linux)
G-Man mówi „Przywróć Monikę”
Podzielam twoją frustrację. Tworzę statyczną stronę internetową i nie mogę mieć wersji lokalnej, która ma folder o nazwie blogz postami na blogu i stronę HTML blogz listą postów na blogu.
Costa

Odpowiedzi:

29

W Linuksie prawie wszystko jest deskryptorem pliku. Katalog to specjalny typ pliku, który z perspektywy użytkownika może przechowywać inne pliki.

Więc nie możesz mieć obu o tej samej nazwie, w tym samym katalogu w tym samym czasie.

Gdybyś mógł, życie koderów stałoby się nieszczęśliwe. Co masz, aby polecenie „isDir” powróciło, gdy ktoś chce utworzyć katalog i sprawdzić, czy istnieje. Czy IsDir („/ home / shrodingers / cat”) powinien zwracać wartość prawda, fałsz czy obie? A czego byś się spodziewał, gdyby ktoś chciał otworzyć katalog pliku w jakimś kodzie?

A co powinien zrobić system, gdy każesz mu coś otworzyć? Załóżmy, że chcesz plik? To oznacza kłopoty ;)

Nawiasem mówiąc: dotyczy to WSZYSTKICH systemów operacyjnych, nie tylko Linuksa. Chociaż z punktu widzenia pulpitu system operacyjny może dodać unikalny identyfikator do pliku lub katalogu i usunąć go z listy. Z punktu widzenia linii poleceń byłoby to jednak problematyczne.

W systemie Windows jest jedna rzecz: używamy nazw z rozróżnianiem wielkości liter. Zatem „MYFILE” i „myfile” to różne rzeczy.

Rinzwind
źródło
2
Nie ma problemu :) Robię to dla entuzjastów ;-)
Rinzwind
1
@Rinzwind dla entuzjastów? Ok, oto kolejny
AB
1
Linuxowa teoria wszystkiego: wszystko jest w formie pliku!
Bajt Dowódca
Anthon i ja współpracowaliśmy przy żartach kota / Schrödingera cztery miesiące temu . I, jak mówi Byte Commander, wyrażenie brzmi „wszystko jest plikiem”, a nie „wszystko jest deskryptorem pliku”.
G-Man mówi „Przywróć Monikę”
1
Plan9 ( plan9.bell-labs.com/plan9 ) (oryginalni twórcy Uniksa) to prawdopodobnie jedyny system operacyjny, w którym „wszystko jest plikiem”. Dla wszystkich innych systemów Unix i Linux poprawne zdanie to „wszystko jest deskryptorem pliku”. „Wszystko jest plikiem” oprócz pamięci, wywołań systemowych, urządzeń sieciowych i prawie wszystkiego oprócz plików ALE wszystkie mają deskryptor pliku ;-) Na wypadek, gdyby ktoś chciał kontynuować to -> czat: =)
Rinzwind
1

nie możesz mieć dwóch podmiotów o tej samej nazwie w tej samej lokalizacji. co się stanie, gdy chcesz cat lub vi plik? jaką jednostkę wybierze system operacyjny? więc ze względu na możliwość pomyłki nie będziesz mieć takiej samej nazwy pliku i folderu w tej samej lokalizacji. a tak na marginesie, folder to plik, który obsługuje inne pliki.

L. Barzic
źródło
3
Twoja odpowiedź rzuca pytanie OP z powrotem na jego twarz („nie możesz mieć dwóch podmiotów o tej samej nazwie w tym samym miejscu”, co on / ona już wyraźnie zna - pytanie brzmi „dlaczego?”), A następnie zadajesz pytania retoryczne , jakby nie można było na nie odpowiedzieć, i to rozwiązało pytanie. Jeśli mam plik i katalog o tej samej nazwie, a ja catlub vitaką nazwę, to oczywiście system operacyjny powinien wybrać plik. Dlaczego to nie działa?
G-Man mówi „Reinstate Monica”
2
@ G-Man: właściwie vito, co zwykle znajduje się vimna Ubuntu, idealnie się otwiera i pokazuje katalog, a nawet go edytuje. Spróbuj: vi .
arielf
1
@arielf: (1) mówiłem, że jeśli to było możliwe dla pliku i podkatalogu o tej samej nazwie istnieje w tym samym katalogu, a następnie, gdy polecenie (głównie) plik zorientowanych takich jak catlub vijest skierowana do tej nazwy , logiczną interpretacją jest wywołanie go w pliku, a nie w podkatalogu. Fakt, że (głównie) zorientowane na plik polecenie ( vi) działa również na (pod) katalog, nie ma znaczenia dla tej instrukcji.
G-Man mówi „Przywróć Monikę”
1
(2) Twoje oświadczenie jest czerwonym śledziem. vimnie naiwnie traktuje argumentów podkatalogów; z tym samym kodem, z którym obsługuje pliki.  vimwydaje się (na bardzo uproszczonym poziomie) dwa programy w jednym: jeśli jest wywoływany w pliku, działa jak edytor tekstu, a jeśli jest wywoływany w podkatalogu, działa jak menedżer plików.
G-Man mówi „Przywróć Monikę”
1
@ G-Man: Odniosłem się tylko do twojego ostatniego stwierdzenia w pierwszym komentarzu: „wtedy system operacyjny powinien wybrać plik”. - za to skoczył na mnie jako nieprawda vi. Twoje zdrowie.
arielf
1

Wiem, że to stary temat, ale właśnie miałem ten sam problem i chciałem się nim podzielić.
Oto moja historia (bądź cierpliwy, jest szczęśliwy koniec).

Środowisko:
jądro Gentoo 4.12.5 64 bity na reiserfs

Jak to się mogło stać?
Mam kilka komputerów z folderem współdzielonym za pomocą synchronizacji. W pewnym momencie w przeszłości usunąłem plik o nazwie „.stfolder” i zamiast tego utworzyłem katalog o tej nazwie. Może więc błąd wynika z synchronizacji synchronizacji tej operacji na innym komputerze.

Teraz zbadajmy błąd: ( działam tutaj jako root )

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

wygląda na to, że plik jest duchem, jednak folder odpowiada normalnie (z funkcją wyszukiwania)

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

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

Wiem, bardzo dziwne ...

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

Nie mogę usunąć tego pliku ducha!

Ale w końcu udało mi się go usunąć, przenosząc go na punkt montowania tmpfs

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

Muszę powiedzieć, że błąd jest nadal obecny na tmpfs, więc nie jest związany z 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

Jak widać na tym wyjściu bash, plik jest obecny i jednocześnie nieobecny. Dzięki tej zdolności kota Schrödingera możemy utworzyć folder o tej samej nazwie.
Ale poczekaj, jest więcej (i powinieneś znaleźć to oczywiste): możemy również stworzyć inny plik o tej samej nazwie.

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"

Ducha można skopiować (więc mogę zduplikować błąd) lub manipulować przez chown, chmod itp. Jedynym ograniczeniem jest to, że nie możesz go nazwać, więc musisz umieścić go w pustym katalogu i użyć „. *” Jako argumenty dla tych poleceń ... ale to działa!

Ze względu na samą naturę ten plik od samego początku był pusty (jest to tylko flaga do synchronizacji).
Byłem więc ciekawy, czy mogę umieścić jakieś dane w tym pliku.
I tutaj przyszło mi rozwiązanie:

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

Tak, w pliku znajduje się niewidoczny znak, tuż za kropką.
To wszystko wyjaśnia.
Dzięki Bogu, nie użyłem „testu echa >>. *” I kota ...

Stopi
źródło
U+200btak przy okazji, to „przestrzeń o zerowej szerokości” . Podoba mi się ta anegdota, choć obawiam się, że może nie być w pełni liczona jako odpowiedź.
PerlDuck
0

/unix//a/238056/139805

wow, to naprawdę dziwne, ale właśnie zrobiłem to, o co prosił autor. Oto jak, więc jest to prawdziwa odpowiedź: 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

zostało to zrobione przez:

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 naprzemiennie odpowiedź dwa pliki o tej samej nazwie, nawet katalog i plik, co się dzieje ??? _

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 

zupełnie dziwne zachowanie

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
źródło
2
Jedna z dwóch nazw ma na końcu jakąś formę spacji. Możesz powiedzieć w wynikach „pliku”.
dascandy