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)?
4 Answers
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.
-
2
-
1
-
1
-
Anthon and I collaborated on the Schrödinger’s cat / both joke four months ago. And, as Byte Commander says, the expression is "Everything is a file", not "everything is a file descriptor." Aug 18, 2015 at 17:28
-
1Plan9 (plan9.bell-labs.com/plan9) (original creators of Unix) is probably the only OS where "everything is a file". For all the other Unix and Linux systems the correct phrase is "everything is a file descriptor". "Everything is a file" except memory, system calls, network devices and pretty much everything except files BUT they all have a file-descriptor ;-) In case someone wants to go on with this -> chat :=)– RinzwindSep 10, 2015 at 10:21
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.
-
4Your answer throws the OP's question back into his face ("you cannot have two entities with the same name in the same location", which he/she clearly already knows — the question is "why?"), and then you ask rhetorical questions, as if they were unanswerable, and that resolved the question. If I have a file and a directory with the same name, and I
cat
orvi
that name, then, obviously, the OS should choose the file. Why can't that work? Aug 18, 2015 at 17:18 -
3@G-Man: actually
vi
which is usuallyvim
on Ubuntu is perfecty happy to open and show a directory and even edit it. Try it:vi .
– arielfAug 22, 2015 at 0:23 -
1@arielf: (1) I was saying that, if it were possible for a file and a subdirectory with the same name to exist in the same directory, then when a (primarily) file-oriented command such as
cat
orvi
is addressed to that name, the logical interpretation is to invoke it on the file rather than on the subdirectory. The fact that a (primarily) file-oriented command (vi
) also works on a (sub)directory is irrelevant to that statement. Aug 27, 2015 at 6:21 -
1(2) Your statement is a red herring.
vim
is not treating subdirectories arguments naïvely; with the same code with which it handles files.vim
seems to be (at a very simplistic level) two programs in one: if it is invoked on a file, it acts like a text editor, and if it is invoked on a subdirectory, it acts like a file manager. Aug 27, 2015 at 6:21 -
1@G-Man: I was only referring to your last assertion in the 1st comment: "then, obviously, the OS should choose the file." - that was what jumped at me as not true for
vi
. Cheers.– arielfAug 28, 2015 at 18:30
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).
Environment:
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...
-
U+200b
is a “zero width space”, by the way. I like this anecdote, although I'm afraid it might not fully count as an answer.– PerlDuckSep 3, 2018 at 13:01
https://unix.stackexchange.com/a/238056/139805
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 #
-
2One of the two names has some form of space at the end. You can tell in the "file" outputs.– dascandyOct 31, 2016 at 16:15
.myfile
?blog
with blog posts in it, and an html page calledblog
with a list of blog posts.-i
flag withls
gives you the ls information with the inode corresponding to each entry. It likely isn't a solution in itself, but can definitely go a ways toward understanding what is going on.