15

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)?

  • Is it named exactly like that ? Does the file have a leading dot in the filename ? For example, .myfile ? – Sergiy Kolodyazhnyy Aug 18 '15 at 12:23
  • I had the same problem. I renamed one. There are several options: Rename the folder to lower case or add an extension, for examples -- myfile or My.File. Or rename the file to MyFile.txt. Renaming either one will work just as well. – Buck Aug 18 '15 at 12:30
  • 3
    Duplicate of Why can't I have a folder and a file with the same name?  (on Unix & Linux) – G-Man Says 'Reinstate Monica' Aug 18 '15 at 17:03
  • I share your frustration. I am building a static website, and I can't have a local version that has a folder called blog with blog posts in it, and an html page called blog with a list of blog posts. – Costa Mar 5 '18 at 23:09
29

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
    No problem :) I do it for the upvotes ;-) – Rinzwind Aug 18 '15 at 12:40
  • 1
    @Rinzwind for the upvotes? Ok, here is another one – A.B. Aug 18 '15 at 13:19
  • 1
    The Linux theory of everything: Everything is file! – Byte Commander Aug 18 '15 at 13:41
  • 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." – G-Man Says 'Reinstate Monica' Aug 18 '15 at 17:28
  • 1
    Plan9 (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 :=) – Rinzwind Sep 10 '15 at 10:21
1

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.

  • 3
    Your 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 or vi that name, then, obviously, the OS should choose the file.  Why can't that work? – G-Man Says 'Reinstate Monica' Aug 18 '15 at 17:18
  • 2
    @G-Man: actually vi which is usually vim on Ubuntu is perfecty happy to open and show a directory and even edit it. Try it: vi . – arielf Aug 22 '15 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 or vi 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. – G-Man Says 'Reinstate Monica' Aug 27 '15 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. – G-Man Says 'Reinstate Monica' Aug 27 '15 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. – arielf Aug 28 '15 at 18:30
1

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. – PerlDuck Sep 3 '18 at 13:01
0

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 # 
  • 2
    One of the two names has some form of space at the end. You can tell in the "file" outputs. – dascandy Oct 31 '16 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.