> On Jan 19, 2018, at 05:23, Jan Stary <[email protected]> wrote:
> 
> This is of course not MP related;
> please kindly point me to the appropriate Apple forum.
> 
> Create a local file:
> 
>       user@local$ echo local > /tmp/file
> 
> Prepare a file on a remote machine,
> with the "same" name, but uppercase:
> 
>       user@remote$ echo remote > /tmp/FILE
> 
> Now copy the remote file to local:
> 
>       user@local$ scp user@remote:/tmp/FILE /tmp/
> 
>       user@local$ cat /tmp/file
>       remote
> 
>       user@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@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@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)?

Reply via email to