In Ubuntu why can't I have a folder named "MyFile" and a document named "MyFile" at the same location? I get an
item already used in this location error. Does Ubuntu / Linux treat folders and files as same objects (pointers to disk)?
In Linux, almost everything is a file descriptor. A directory is a special type of file that from the user's perspective can hold other files.
So you can not have both with the same name, in the same directory at the same time.
If you could, life would become miserable for coders. What would you have the command "isDir" return when someone wants to create a directory and check for it to exists. Should isDir("/home/shrodingers/cat") return true, false or both? And what would you expect if someone wants to open a dir of a file in some code?
And what should the system do when you tell it to open something? Assume you want the file? That spells trouble ;)
By the way: this is true for ALL operating systems, not just Linux. Though from a Desktop point of view an operating system could add a unique identifier to the file or directory and remove it from the listing. From a command line point of view it would problematic though.
There is one thing we have over Windows: we use case-sensitive names. So "MYFILE" and "myfile" are different things.
you cannot have two entities with the same name in the same location. what will happen when you want to cat or vi the file? witch entity will the OS chose? so because of confusion possibility you will not be able to have same name for a file and folder in the same location. and by the way a folder is a file that host other files.
I know this is an old topic, but I just had the same issue and I wanted to share.
Here is my story (be patient, there's a happy end).
Gentoo kernel 4.12.5 64bits on reiserfs
How this could happened ?
I've several machine with a folder shared using syncthing. At some point in the past, I've removed a file named ".stfolder" and create a directory with that name, instead. So maybe the bug is due to syncthing synchronizing this operation on another machine.
Now let's examine the bug: (I'm operating as root here)
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
looks like the file is a ghost however the folder is answering normally (with find)
file .* .: directory ..: directory .stfolder: directory .stfolder: empty .stignore: C source, ASCII text file .s* .stfolder: directory .stignore: C source, ASCII text
I know, very weird...
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
I can't remove that ghost file!
But in the end, I've successfully removed it by moving it on a tmpfs mount point
mv .stfolder /elsewhere/ mv: impossible d'évaluer '.stfolder': Aucun fichier ou dossier de ce type mv .* /elsewhere/
I must say that the bug is still present on tmpfs, so not related to 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
As you can see in this bash output, the file is present and not-present at the same time. Because of this Schrödinger cat ability, we can create a folder with the same name.
But wait, there's more (and you should find this obvious) : we can create another file with the same name too.
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"
The ghost can be copied (so I can duplicate the bug), or manipulated by chown, chmod, etc. the only restriction is you can't name it so you have to put it in an empty directory and use ".*" as arguments for those commands... but it works!
Because of the very nature of it, this file was empty from the begining (it's just a flag for syncthing).
So I was curious if I could put some data in that file.
And here, the solution came to me :
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
Yes, there is an invisible character in that file, just after the dot.
This explains everything.
Thanks god, I didn't use "echo test >> .*" and cat...
wow this is really weird but I just did what the author asked. This is how, so it is a real answer :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
this was done by:
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 alternate response two files with the same name, not even a directory and a file anymore what is going on ???_
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
totally strange behaviour
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 #