Те саме ім'я папки та файлу в одному місці


15

Чому в Ubuntu я не можу в тому самому місці мати папку з назвою "MyFile" та документ під назвою "MyFile"? Я отримую item already used in this locationпомилку. Чи трактує Ubuntu / Linux папки та файли як однакові об’єкти (покажчики на диск)?


Це названо саме так? Чи має у файлі провідна крапка у назві файлу? Наприклад .myfile,?
Сергій Колодяжний

У мене була така ж проблема. Я перейменував один. Є кілька варіантів: Перейменуйте папку в малі регістри або додайте розширення, наприклад, myfile або My.File. Або перейменуйте файл у MyFile.txt. Перейменування будь-якого з них працюватиме так само добре.
Бак


Я поділяю ваше розчарування. Я будую статичний веб-сайт, і я не можу мати локальну версію, яка містить папку з назвою blogв ній, і сторінку HTML, яку називають blogсписком публікацій блогу.
Коста

Відповіді:


29

В Linux майже все є дескриптором файлів. Каталог - це особливий тип файлів, який з точки зору користувача може вміщувати інші файли.

Таким чином, ви не можете мати обох з тим самим іменем, в одному каталозі одночасно.

Якби ти міг, життя стало б нещасним для кодерів. Що б ви мали команду "isDir" повернути, коли хтось хоче створити каталог і перевірити, чи існує він. Чи повиненDir ("/ home / shrodingers / cat") повертати справжнє, хибне чи те й інше? А що б ви очікували, якщо хтось захоче відкрити dir файлу в якомусь коді?

І що повинна робити система, коли ти кажеш їй щось відкрити? Припустимо, ви хочете файл? Це вимовляє неприємності ;)

До речі: це справедливо для ВСІХ операційних систем, а не лише для Linux. Хоча з точки зору робочого столу операційна система може додати унікальний ідентифікатор до файлу чи каталогу та видалити його із списку. З точки зору командного рядка, це було б проблематично.

У Windows є одна річ: ми використовуємо чутливі до регістру імена. Отже "MYFILE" та "myfile" - це різні речі.


2
Немає жодних проблем :) Я це роблю для upvotes ;-)
Rinzwind

1
@Rinzwind для анонсів? Гаразд, ось ще одна
AB

1
Теорія Linux про все: все є файлом!
Байт-командир

Ми з Антоном співпрацювали над котом Шредінгера / обидва жартували чотири місяці тому . І, як каже командувач Byte, вираз - "Все - файл", а не "все - дескриптор файлу".
G-Man каже: "Відновіть Моніку"

1
Plan9 ( plan9.bell-labs.com/plan9 ) (оригінальні творці Unix), мабуть, єдина ОС, де "все є файлом". Для всіх інших систем Unix та Linux правильною фразою є "все - дескриптор файлів". "Все - файл", за винятком пам'яті, системних дзвінків, мережевих пристроїв і майже всього, крім файлів, АЛЕ всі вони мають файловий дескриптор ;-) У разі, якщо хтось хоче продовжувати це -> чат: =)
Rinzwind

1

у вас не може бути двох об'єктів з однаковим іменем в одному і тому ж місці. що станеться, коли ви захочете перенести файл чи файл vi? яку відьому обрала ОС? тому через можливість плутанини ви не зможете мати однакове ім’я для файлу та папки в одному місці. і до речі папка - це файл, у якому розміщені інші файли.


3
Ваша відповідь кидає запитання ОП в його обличчя ("ви не можете мати два об'єкти з однаковою назвою в одному місці", яке він / вона вже чітко знає - питання "чому?"), А потім ви задаєте риторичні питання , наче вони були невідчутні, і це вирішило питання. Якщо у мене є файл і каталог з тим самим іменем, і я catчи viце ім'я, тоді, очевидно, ОС повинна вибрати файл. Чому це не може працювати?
G-Man каже: "Відновіть Моніку"

2
@ G-Man: насправді, viщо зазвичай є vimна Ubuntu, із задоволенням відкриває та показує каталог та навіть редагує його. Спробуйте: vi .
arielf

1
@arielf: (1) Я говорив, що, якщо в одному і тому ж каталозі можна було б існувати файл і підкаталог з тим самим іменем, то коли (в першу чергу) команда, орієнтована на файл, наприклад, catабо viадресована цьому імені , логічна інтерпретація полягає в тому, щоб викликати його у файлі, а не у підкаталозі. Те, що (в першу чергу) команда, орієнтована на файли ( vi), також працює в (під) каталозі, не має значення для цього твердження.
G-Man каже: "Відновіть Моніку"

1
(2) Ваша заява - це червона оселедець. vimне ставиться до аргументів підкаталогів наївно; з тим самим кодом, з яким він обробляє файли.  vimздається, що (на дуже спрощеному рівні) дві програми в одній: якщо його викликають у файлі, він діє як текстовий редактор, а якщо його викликають у підкаталозі, він діє як файловий менеджер.
G-Man каже: "Відновіть Моніку"

1
@ G-Man: Я мав на увазі лише ваше останнє твердження в 1-му коментарі: "тоді, очевидно, ОС повинна вибрати файл". - це те, що стрибнуло на мене, як неправда vi. Ура.
аріельф

1

Я знаю, що це стара тема, але у мене просто було те саме питання, і я хотів поділитися.
Ось моя історія (будьте терплячі, там щасливий кінець).

Навколишнє середовище:
ядро Gentoo 4.12.5 64 біт на рейзерфі

Як це могло статися?
У мене є декілька машин із папкою, якою поділено синхронізацію. Якось у минулому я видалив файл з назвою ".stfolder" і створив натомість каталог із цим ім'ям. Тож можливо помилка пов’язана із синхронізацією синхронізації цієї операції на іншій машині.

Тепер вивчимо помилку: (я тут працюю як 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

схоже, що файл - привид, проте папка відповідає нормально (з пошуку)

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

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

Я знаю, дуже дивно ...

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

Я не можу видалити цей привидний файл!

Зрештою, я його успішно видалив, перемістивши його на точку монтування tmpfs

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

Треба сказати, що помилка все ще присутня на tmpfs, тому не пов’язана з 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

Як ви бачите в цьому виведенні bash, файл одночасно присутній і не присутній. Через цю здатність кота Шредінгера ми можемо створити папку з такою ж назвою.
Але зачекайте, є більше (і вам це здається очевидним): ми також можемо створити ще один файл з такою ж назвою.

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"

Привид може бути скопійований (так що я можу дублювати помилку), або маніпулювати chown, chmod тощо. Єдине обмеження - ви не можете його назвати, тому вам доведеться помістити його в порожній каталог і використовувати ". *" Як аргументи для цих команд ... але це працює!

Через саму природу цього файлу спочатку було порожньо (це лише прапор для синхронізації).
Тож мені було цікаво, чи зможу я помістити деякі дані у цей файл.
І ось до мене прийшло рішення:

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

Так, у цьому файлі є невидимий символ, одразу після крапки.
Це пояснює все.
Слава Богу, я не використовував "ехо-тест >>. *" І котячий ...


U+200bце , до речі, «простір нульової ширини» . Мені подобається цей анекдот, хоча я боюся, що він не може повністю вважатись відповіддю.
PerlDuck

0

/unix//a/238056/139805

Уау, це справді дивно, але я просто зробив те, що запитував автор. Ось як, тому це справжня відповідь: 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

це зробили:

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

хто чергує відповідь два файли з однаковим іменем, навіть не каталог і файл більше, що відбувається ??? _

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 

абсолютно дивна поведінка

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 # 

2
Одне з двох імен має в кінці певну форму пробілу. Ви можете сказати у «файлі» виходи.
дасканді
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.