scp ignores case in filenames?

[Richard L. Hamilton]

> On Jan 19, 2018, at 05:23, Jan Stary <hans at stare.cz> wrote:
> 
> This is of course not MP related;
> please kindly point me to the appropriate Apple forum.
> 
> Create a local file:
> 
> 	user at local$ echo local > /tmp/file
> 
> Prepare a file on a remote machine,
> with the "same" name, but uppercase:
> 
> 	user at remote$ echo remote > /tmp/FILE
> 
> Now copy the remote file to local:
> 
> 	user at local$ scp user at remote:/tmp/FILE /tmp/
> 
> 	user at local$ cat /tmp/file
> 	remote
> 
> 	user at local$ ls -li /tmp/FILE /tmp/file
> 	5155210 -rw-r--r--  1 hans  wheel  7 Jan 19 11:19 /tmp/FILE
> 	5155210 -rw-r--r--  1 hans  wheel  7 Jan 19 11:19 /tmp/file
> 
> This is MacOS 10.13.2. Is this expected?
> I see it but I don't believe it.
> 
> Jan

By default, macOS (like Windows with NTFS filesystem) is case-preserving but NOT case-sensitive.  In other words, names that differ only by case refer to the same file.  If you did something like ls -l /tmp|grep -i file, you'd see the "real" case of the file name; but given names on the command line as in your example, it's simply showing the case as you referred to it.

Here's pretty much the same scenario, but with more detail:
sh-3.2$ cd /tmp
sh-3.2$ touch file;ls -li file
8630716 -rw-r--r--  1 rlhamil  wheel  0 Jan 19 06:02 file
sh-3.2$ ssh rlhamil at myeye 'touch /tmp/FILE;cd /tmp;ls -li|grep -i file'
337300704 -rw-r--r--  1 rlhamil  wheel    0 Jan 19 06:03 FILE
sh-3.2$ scp rlhamil at myeye:/tmp/FILE /tmp
FILE                                          100%    0     0.0KB/s   00:00    
sh-3.2$ ls -li|grep -i file
8630716 -rw-r--r--  1 rlhamil  wheel   0 Jan 19 06:03 file

Notice that the inode number for the local /tmp/file is the same before and after the scp.  So it did not re-create the file, but merely truncated it and overwrote it  (being case-insensitive, "file" regardless of how capitalized referred to the same file).  If it had, the new capitalization would probably have been picked up, but since it didn't, the existing capitalization was unchanged.

For a case-preserving but case-insensitive filesystem, the behavior was exactly as I'd expect.

One can create either HFS+ or APFS filesystems to be case-sensitive, but for backwards compatibility with macOS's pre-Unix ancestors, that is obviously not the default.  Ideally, all programs would refer consistently to file names, so except for how a human types them in, it wouldn't matter.  But any exception would be broken on a case-sensitive filesystem; is it worth the risk of breakage to switch (I have seen some in the past that would have broken)?  Is it worth the inconvenience of having to enter case correctly (for those not already accustomed to doing that)?