The command is simple enough, executed while in a subdirectory of /mnt/e, an external drive: cp -r ~/.config .. Every time, every time I run it, the same set of files refuse to copy properly:

cp: cannot create regular file './.config/yarn/global/node_modules/ws/lib/validation.js': File exists cp: cannot create regular file './.config/yarn/global/node_modules/ws/lib/websocket.js': File exists cp: cannot create regular file './.config/yarn/global/node_modules/ws/lib/sender.js': File exists cp: cannot create regular file './.config/yarn/global/node_modules/ws/lib/constants.js': File exists cp: cannot create regular file './.config/yarn/global/node_modules/ws/lib/receiver.js': File exists cp: cannot create regular file './.config/yarn/global/node_modules/debug/Readme.md': File exists

The files certainly do not exist when I execute the command, and besides, adding the parameter -f makes no difference. But wait, it gets bizarre here. The system does copy the files, sort of, but they end up having very different contents. The differences can't be explained by a corrupted copy. If I run a diff of that Readme.md file:

diff -u ~/.config/yarn/global/node_modules/debug/Readme.md ./.config/yarn/global/node_modules/debug/Readme.md

I find these two lines in the output:

- Note that PowerShell using different syntax to set environment variables. + Note that PowerShell uses different syntax to set environment variables.

What is going on here?! It's as if I'm getting a newer version of the file when I run the copy. The thing is, every time I run the command I end up with the same differences in that particular file, which makes no damn sense.

Clearly I must be in over my head here. I read the answer at cannot create regular file 'filename': File exists but I don't get it. I tried using the strace script in the answer but I hit a wall there (no trace file was created). I'm just a caveman Linux user, I'm not even using "real" Linux but WSL (Ubuntu 16.04), so can someone explain in simple language what the problem is here? Clearly some process is interfering, that much I can guess, but otherwise I'm clueless.


OK, I've determined that the problem is that in the source subdirectories there exist files with the same name just different case (Validation.js, WebSocket.js, etc.). The problem would appear that, as a WSL user, I'm copying to a drive that was formatted by Windows and so does not support case-sensitive subdirectories. However, cursory research reveals that since Windows 10 version 1803 (which I have) case-sensitive subdirectories on NTFS file systems are possible. Furthermore, WSL-created subdirectories are automatically case-sensitive (link):

Linux tools you run inside the Windows Subsystem for Linux (Bash shell) now create folders with the case sensitive flag set. So, whether you use the mkdir command to create a directory inside a Bash shell or a development tool does it for you, the created directory is automatically set as case sensitive—even if you create it on your mounted Windows file system.

I did not create the destination subdirectory in WSL, so I deleted it and re-created it in WSL. My problem still persists, though, even though it shouldn't. Any ideas?

  • I would suspect that there is a regular files on the destination that is a directory on the source, or vice versa. – wurtel Jul 15 at 10:58

Your Answer

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

Browse other questions tagged or ask your own question.