0

Ok so i did something very stupid (copying a file and renaming it '.') since I thought it would just copy it as .uniprot_sprot.fasta.gz.icloud.

cp /path/.uniprot_sprot.fasta.gz.icloud .

and now I don't know how to remove it from current directory as it would be removing '.' itself.

What can I do? This doesn't work. It says: No such file or directory

rm .uniprot_sprot.fasta.gz.icloud

On the other hand:

ls -a

gives this:

.
..
uniprot_sprot.fasta.gz.icloud
Cyrus
  • 84,225
  • 14
  • 89
  • 153
Caterina
  • 775
  • 9
  • 26
  • why would your second command work? no such file has been made. – 2e0byo Jan 11 '22 at 18:40
  • So you renamed it after copying it? Then, uh, remove the file as it is *now* named. – Jeff Holt Jan 11 '22 at 18:42
  • Your file can't be named `.`, and indeed, your `ls -a` command output shows it isn't the case (`.` stands for the current directory). You probably renamed it at some point. Anyways, you now only need this command to remove your file: `rm uniprot_sprot.fasta.gz.icloud`. – gniourf_gniourf Jan 11 '22 at 18:44

1 Answers1

1

You have not copied a file and renamed it . (at any rate if you're running a sane *nix). Instead you have copied the file to the current directory with the name of the original file. (If you pass a directory to cp as the destination, files will be placed in that directory. . is the current directory, so this is all that has happened.) If you want to remove it you can just rm uniprot_sprot.fasta.gx.iscloud or explicitly rm ./uniprot_sprot.fasta.gx.iscloud. What you have tried to do is to remove a file whose name starts with ., which is a different thing.

Edit: I was unaware when I wrote this, but this is in fact simply down to . existing as a real, regular hardlink. At syscall level you can create a file whose name contains anything except / and \x00 (yep, including \n), assuming your filesystem allows it. However, the links . and .. are already present and thus unavailable as a file name. @thatotherguy links to the kernel source for the rmdir syscall, showing that in modern Linux at least it is the kernel itself which ultimately prevents you from deleting . and ...

Note that in bash, . at the beginning of a line by itself means source.

See this question on unix.se and its linked dupe for more information on the filename problem.

2e0byo
  • 5,305
  • 1
  • 6
  • 26
  • Ok thanks. I thought if you copied a file starting with "." it would copy it exactly like that in the current directory – Caterina Jan 11 '22 at 18:45
  • *nix forbids calling any file `.`, since `.` is the curent directory (`..` is forbidden for the same reason). You *can't* make forbidden files under *nix (unless something is broken). Compare that to the trivial ease with which you can make files on windows which it is then nigh-on impossible to delete from explorer... – 2e0byo Jan 11 '22 at 18:47
  • incidentally see https://stackoverflow.com/questions/1976007/what-characters-are-forbidden-in-windows-and-linux-directory-names for some discussion of what you can and can't do. I don't actually know if the prohibition on `.` is enforced in the kernel (I'm guessing so), the shell, or the filesystem, or whether it's possible to create nasty files in some underhand way on linux. for more information see e.g. [this question on unix.se](https://unix.stackexchange.com/questions/230291/what-characters-are-valid-to-use-in-filenames). – 2e0byo Jan 11 '22 at 18:55
  • 1
    `.` and `..` are exposed as regular directory links (so not handled by the shell), and in original UNIX they were created as such by the `mkdir` program. Today the kernel and FS collaborate on making sure they exist and point to the correct place. On Linux, [the `rmdir` syscall itself is responsible](https://github.com/torvalds/linux/blob/6f38be8f2ccd9babf04b9b23539108542a59fcb8/fs/namei.c#L4005-L4007) for avoiding deletion, while the inability to create a file with the name `.` is simply due to a directory by that name necessarily already existing. – that other guy Jan 11 '22 at 19:20