bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Keith David Bershatsky]

On an Emacs build (master branch), using Emacs -Q, I am unable to change files and folders in dired-mode from CamelCase/UPPERCASE/lowercase.

A folder named `FOO` cannot be changed to `foo` using `dired-do-rename`.

    Move ‘/Users/HOME/Desktop/FOO’ to ‘/Users/HOME/Desktop/foo/FOO’ failed:
      (file-error Renaming Invalid argument /Users/HOME/Desktop/FOO /Users/HOME/Desktop/foo/FOO)

Any ideas how to accomplish this on OSX with drives that are formatted as Mac OS Extended (Journaled)?

Thanks,

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

In GNU Emacs 25.1.50.1 (x86_64-apple-darwin10.8.0, NS appkit-1038.36 Version 10.6.8 (Build 10K549))
 of 2015-12-07
Repository revision: 6148555ee5a3d0139ae517803718b3e0357933c7
Windowing system distributor 'Apple', version 10.3.1038
Configured using:
 'configure --with-ns --without-imagemagick --enable-checking=glyphs
 CPPFLAGS=-I/Users/HOME/.0.data/.0.emacs/macports/include
 LDFLAGS=-L/Users/HOME/.0.data/.0.emacs/macports/lib'

Configured features:
JPEG RSVG DBUS NOTIFY ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

Important settings:
  locale-coding-system: utf-8-unix

Major mode: FM

Minor modes in effect:
  tb-mode: t
  sb-mode: t
  ml-mode: t
  ds-mode: t
  sd-mode: t
  bc-mode: t

Recent messages:

Load-path shadows:
None found.

Features:
(shadow emacsbug message mml mml-sec mm-decode mm-bodies mm-encode
gmm-utils mailheader sendmail lawlist-ztree lawlist-ys lawlist-ws
lawlist-wl elmo-imap4 elmo-localdir modb-standard modb-legacy
elmo-internal elmo-flag mmelmo-imap mmelmo-buffer elsp-generic mel-u
epg-config lawlist-w3m doc-view jka-compr image-mode ccl lawlist-vl
lawlist-view lawlist-undo lawlist-txt lawlist-tm lawlist-tex compare-w
diff-mode lawlist-tabbar lawlist-speedbar lawlist-shell info
esh-groups ehelp ange-ftp lawlist-sgml lawlist-sb lawlist-ruler
lawlist-replace lawlist-rectangle lawlist-re-builder lawlist-python
skeleton lawlist-profiler lawlist-print lawlist-php cl-seq cc-langs
lawlist-perl lawlist-parens lawlist-org lawlist-calendar org-agenda
org org-macro org-footnote org-pcomplete org-list org-faces
org-entities org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-src ob-keys ob-comint ob-core ob-eval org-compat
org-macs org-loaddefs find-func holidays hol-loaddefs cal-menu
calendar cal-loaddefs lawlist-neotree lawlist-movement lawlist-mouse
lawlist-ml lawlist-misc lawlist-messages lawlist-mc lawlist-markdown
noutline outline lawlist-lorem lawlist-linum lawlist-keymap lawlist-js
json map thingatpt cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs lawlist-ispell
lawlist-isearch lawlist-info lawlist-imenu lawlist-ibuffer lawlist-hl
lawlist-grep lawlist-git pcvs-util ido seq server conf-mode
lawlist-framebufs lawlist-frame lawlist-fm lawlist-files zeroconf dbus
xml lawlist-env lawlist-elscreen lawlist-elisp lawlist-dv
lawlist-image lawlist-ds lawlist-dired dired format-spec lawlist-diff
lawlist-desktop frameset lawlist-saveplace lawlist-debug
lawlist-window debug lawlist-css smie lawlist-compile rx lawlist-color
lawlist-cm lawlist-cc lawlist-font-lock cl-macs lawlist-calc
lawlist-calc+ lawlist-bk lawlist-bc lawlist-bbdb gnus gnus-ems
nnheader mail-utils wid-edit mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev mail-extr rfc822 timezone lawlist-minibuffer gv
lawlist-auth gnus-util mm-util help-fns mail-prsvr password-cache
lawlist-as lawlist-archive lawlist-apropos lawlist-+ lawlist-lcl
byte-opt bytecomp byte-compile cl-extra cconv lawlist-help disp-table
easy-mmode edmacro kmacro quail help-mode easymenu cl-loaddefs cl-lib
pcase derived advice shell pcomplete comint ansi-color ring savehist
time-date mule-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel ns-win term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame
cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
minibuffer cl-preloaded nadvice loaddefs button faces cus-face
macroexp files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
dbusbind kqueue cocoa ns multi-tty make-network-process emacs)

Memory information:
((conses 16 2354572 210705)
 (symbols 48 86149 13)
 (miscs 40 615 539)
 (strings 32 193947 18434)
 (string-bytes 1 7215369)
 (vectors 16 37672)
 (vector-slots 8 1005865 24059)
 (floats 8 2731 483)
 (intervals 56 602 119)
 (buffers 976 12))

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[John Wiegley]

>>>>> Keith David Bershatsky <esq@lawlist.com> writes:

> Any ideas how to accomplish this on OSX with drives that are formatted as
> Mac OS Extended (Journaled)?

Hi Keith,

Since this is not an Emacs bug, I'm closing this report, but here is what I do
that should work for you:

  1. Rename the file to 'x'.
  2. Rename 'x' to the correctly cased name.

Copy the name to the kill-ring before #1, so that you can paste it in when
asked by #2.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Drew Adams]

> Since this is not an Emacs bug, I'm closing this report, but here is what I
> do that should work for you:
> 
>   1. Rename the file to 'x'.
>   2. Rename 'x' to the correctly cased name.
> 
> Copy the name to the kill-ring before #1, so that you can paste it in when
> asked by #2.

Hm.  I'm curious.  How do we know that this is not an Emacs bug?

I do not understand why this is his error msg:

    Move '/Users/HOME/Desktop/FOO' to '/Users/HOME/Desktop/foo/FOO' failed:
                              ^^^                          ^^^^^^^
      (file-error Renaming Invalid argument 
       /Users/HOME/Desktop/FOO/Users/HOME/Desktop/foo/FOO)

That looks peculiar, if all he did was hit `R' on a directory name.
That message seems to be saying that Emacs asked the OS to move
directory .../FOO to .../foo/FOO.  That doesn't seem like the right
thing for Emacs to do.  Seems like Emacs should have asked the OS
to move .../FOO to .../foo (without the trailing /FOO).

Am I missing something?

Also, I see from Keith's StackExchange question about this that
he is able to use `mv FOO foo' to do the renaming without a problem.
http://emacs.stackexchange.com/q/19234/105

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[John Wiegley]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

> Hm. I'm curious. How do we know that this is not an Emacs bug?

His description matches something I run into myself all the time, due to
Emacs's case insensitive filesystem:

    17:10:45 Vulcan:/tmp $ mv foo Foo
    mv: ‘foo’ and ‘Foo’ are the same file

> I do not understand why this is his error msg:

>     Move '/Users/HOME/Desktop/FOO' to '/Users/HOME/Desktop/foo/FOO' failed:
>                               ^^^                          ^^^^^^^
>       (file-error Renaming Invalid argument 
>        /Users/HOME/Desktop/FOO/Users/HOME/Desktop/foo/FOO)

Good catch, I hadn't noticed this oddity. Maybe this particular case is a real
bug.

> Also, I see from Keith's StackExchange question about this that he is able
> to use `mv FOO foo' to do the renaming without a problem.
> http://emacs.stackexchange.com/q/19234/105

If that's the case, it sounds like a real bug, I'll reopen.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Drew Adams]

> > Hm. I'm curious. How do we know that this is not an Emacs bug?
> 
> His description matches something I run into myself all the time, due to
> Emacs's case insensitive filesystem:
> 
>     17:10:45 Vulcan:/tmp $ mv foo Foo
>     mv: ‘foo’ and ‘Foo’ are the same file

Okay.  But (1) he _is_ able to do it using `mv foo Foo', and
(2) MS Windows is also case-insensitive for files and folders,
and I can easily use `R' to rename a directory `foo' to `FOO',
and vice versa.  (Emacs asks me to confirm that I want to rename,
but that's all.)

> > I do not understand why this is his error msg:
> 
> >     Move '/Users/HOME/Desktop/FOO' to '/Users/HOME/Desktop/foo/FOO'
> failed:
> >                               ^^^                          ^^^^^^^
> >       (file-error Renaming Invalid argument
> >        /Users/HOME/Desktop/FOO/Users/HOME/Desktop/foo/FOO)
> 
> Good catch, I hadn't noticed this oddity. Maybe this particular case is a
> real bug.
> 
> > Also, I see from Keith's StackExchange question about this that he is able
> > to use `mv FOO foo' to do the renaming without a problem.
> > http://emacs.stackexchange.com/q/19234/105
> 
> If that's the case, it sounds like a real bug, I'll reopen.

Thanks.

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Eli Zaretskii]

> Date: Sun, 03 Jan 2016 12:57:27 -0800
> From: Keith David Bershatsky <esq@lawlist.com>
> 
> On an Emacs build (master branch), using Emacs -Q, I am unable to change files and folders in dired-mode from CamelCase/UPPERCASE/lowercase.
> 
> A folder named `FOO` cannot be changed to `foo` using `dired-do-rename`.
> 
>     Move ‘/Users/HOME/Desktop/FOO’ to ‘/Users/HOME/Desktop/foo/FOO’ failed:
>       (file-error Renaming Invalid argument /Users/HOME/Desktop/FOO /Users/HOME/Desktop/foo/FOO)

Why is it trying to make a directory into a subdirectory of itself?

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Keith David Bershatsky]

I won't be of very much help debugging the C-source code issue of `rename-file`:

  (let ((default-directory "/Users/HOME/Desktop/"))
    (rename-file "/Users/HOME/Desktop/FOO" "/Users/HOME/Desktop/foo" 'ok-if-already-exists))

which yields the following debugger output:

  (file-error "Renaming" "Invalid argument" "/Users/HOME/Desktop/FOO" "/Users/HOME/Desktop/foo/FOO")


However, part of the `dired` problem stems from the outset of `dired-create-files' when the let-bound variable `to' is initially set based on the `name-constructor':

name-constructor:  (lambda (from) (expand-file-name (file-name-nondirectory from) target))

from:  "/Users/HOME/Desktop/FOO"

target:  "/Users/HOME/Desktop/foo"

Put it all together and we have:

  (funcall (lambda (from) (expand-file-name (file-name-nondirectory from) "/Users/HOME/Desktop/foo" )) "/Users/HOME/Desktop/FOO")

Which yields the erroneous `to`:  "/Users/HOME/Desktop/foo/FOO"

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Mon, 04 Jan 2016 05:31:38 +0200,
Eli Zaretskii wrote:
> 
>  Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
> 
> > Date: Sun, 03 Jan 2016 12:57:27 -0800
> > From: Keith David Bershatsky <esq@lawlist.com>
> > 
> > On an Emacs build (master branch), using Emacs -Q, I am unable to change files and folders in dired-mode from CamelCase/UPPERCASE/lowercase.
> > 
> > A folder named `FOO` cannot be changed to `foo` using `dired-do-rename`.
> > 
> >     Move ‘/Users/HOME/Desktop/FOO' to ‘/Users/HOME/Desktop/foo/FOO' failed:
> >       (file-error Renaming Invalid argument /Users/HOME/Desktop/FOO /Users/HOME/Desktop/foo/FOO)
> 
> Why is it trying to make a directory into a subdirectory of itself?

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Eli Zaretskii]

> Date: Sun, 3 Jan 2016 16:47:32 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 22300-done@debbugs.gnu.org
> 
> Hm.  I'm curious.  How do we know that this is not an Emacs bug?

Because we can step through the code, or just plain read it ;-)

> I do not understand why this is his error msg:
> 
>     Move '/Users/HOME/Desktop/FOO' to '/Users/HOME/Desktop/foo/FOO' failed:
>                               ^^^                          ^^^^^^^
>       (file-error Renaming Invalid argument 
>        /Users/HOME/Desktop/FOO/Users/HOME/Desktop/foo/FOO)
> 
> That looks peculiar, if all he did was hit `R' on a directory name.
> That message seems to be saying that Emacs asked the OS to move
> directory .../FOO to .../foo/FOO.  That doesn't seem like the right
> thing for Emacs to do.  Seems like Emacs should have asked the OS
> to move .../FOO to .../foo (without the trailing /FOO).

Would you still think that if the arguments were changed as below?

  Move '/Users/HOME/Desktop/FOO' to '/Users/HOME/Desktop/bar/FOO'

> Am I missing something?

Yes, you are:

  . The filesystem in question is evidently case-insensitive, so Emacs
    thinks the user wants to move a directory into another _existing_
    directory ('foo' exists because 'FOO' does)

  . When the target is an existing directory, rename-file _always_
    behaves like shown above (which is actually what the user should
    expect, don't you agree?)

  . See my other message

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Eli Zaretskii]

> Date: Sun, 3 Jan 2016 17:37:37 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 22300-done@debbugs.gnu.org, Keith David Bershatsky <esq@lawlist.com>
> 
> > His description matches something I run into myself all the time, due to
> > Emacs's case insensitive filesystem:
> > 
> >     17:10:45 Vulcan:/tmp $ mv foo Foo
> >     mv: ‘foo’ and ‘Foo’ are the same file
> 
> Okay.  But (1) he _is_ able to do it using `mv foo Foo', and
> (2) MS Windows is also case-insensitive for files and folders,
> and I can easily use `R' to rename a directory `foo' to `FOO',
> and vice versa.  (Emacs asks me to confirm that I want to rename,
> but that's all.)

For some value of "easily", yes.  On the C source level, Emacs works
very hard (a.k.a. "jumps through hoops") to allow you doing that
easily, and it does that only for MS-Windows and MS-DOS, whose
filesystems are known to be case-insensitive.  OS X doesn't have that
privilege.

If OS X filesystems are always case-insensitive, perhaps the same code
should also be compiled on that system.  If some of OS X filesystems
are case-sensitive, we can only do that if Emacs can know which one is
it.

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Eli Zaretskii]

> Date:  Sun, 03 Jan 2016 20:19:50 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  22300@debbugs.gnu.org,Drew Adams <drew.adams@oracle.com>,John Wiegley <jwiegley@gmail.com>
> 
>   (let ((default-directory "/Users/HOME/Desktop/"))
>     (rename-file "/Users/HOME/Desktop/FOO" "/Users/HOME/Desktop/foo" 
> 'ok-if-already-exists))
> 
> which yields the following debugger output:
> 
>   (file-error "Renaming" "Invalid argument" "/Users/HOME/Desktop/FOO" "/Users/HOME/Desktop/foo/FOO")

This is expected, if your filesystem is case-insensitive.  See my
other messages for the explanation why.

The question is: are all OS X filesystems case-insensitive.  If they
are, we just need to reuse the DOS_NT code that's already in
rename-file.

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Drew Adams]

> > I do not understand why this is his error msg:
> >
> >     Move '/Users/HOME/Desktop/FOO' to '/Users/HOME/Desktop/foo/FOO'
> > failed:
> >                               ^^^                          ^^^^^^^
> >       (file-error Renaming Invalid argument
> >        /Users/HOME/Desktop/FOO/Users/HOME/Desktop/foo/FOO)
> >
> > That looks peculiar, if all he did was hit `R' on a directory name.
> > That message seems to be saying that Emacs asked the OS to move
> > directory .../FOO to .../foo/FOO.  That doesn't seem like the right
> > thing for Emacs to do.  Seems like Emacs should have asked the OS
> > to move .../FOO to .../foo (without the trailing /FOO).
> 
> Would you still think that if the arguments were changed as below?
> 
>   Move '/Users/HOME/Desktop/FOO' to '/Users/HOME/Desktop/bar/FOO'

I don't understand why you ask that.  He (presumably) asked, interactively,
to move the directory from .../FOO to .../foo.  At least that's my
understanding of what he did - that's what he's said.  And when I do that
on MS Windows that's all that happens: FOO is renamed to foo.

In his case, it seems that the target is getting interpreted as .../foo/FOO.

Isn't the whole question here just what the "arguments" are?

> > Am I missing something?
> 
> Yes, you are:
> 
>   . The filesystem in question is evidently case-insensitive, so Emacs
>     thinks the user wants to move a directory into another _existing_
>     directory ('foo' exists because 'FOO' does)

Why would Emacs think that?  It doesn't think that when I do the same
thing on MS Windows.  He has said that he did exactly what I did, when
I told Emacs to rename "FOO" to "foo".

>   . When the target is an existing directory, rename-file _always_
>     behaves like shown above (which is actually what the user should
>     expect, don't you agree?)

See previous.  Dunno what you mean by it always behaving like you say.
`R' in Dired on MS Windows simply renames FOO to foo, if point is on
directory FOO and you type only "foo" as the new name.

According to what Keith has said, that is not the behavior he gets on
his OS.  He tells Emacs to rename the directory to "foo", and it
(apparently) tries to move (rename) it from FOO to foo/FOO.

>   . See my other message

OK.  Your other message says that MS Windows handles `R' correctly
because it knows that Windows file/folder names are handled
case-insensitively.  And it suggests that this is not the case for OS X.

So that's the bug (or enhancement request): Emacs should treat OS X
file/folder names appropriately.

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Drew Adams]

> > Okay.  But (1) he _is_ able to do it using `mv foo Foo', and
> > (2) MS Windows is also case-insensitive for files and folders,
> > and I can easily use `R' to rename a directory `foo' to `FOO',
> > and vice versa.  (Emacs asks me to confirm that I want to rename,
> > but that's all.)
> 
> For some value of "easily", yes.  On the C source level, Emacs works
> very hard (a.k.a. "jumps through hoops") to allow you doing that
> easily, and it does that only for MS-Windows and MS-DOS, whose
> filesystems are known to be case-insensitive.  OS X doesn't have that
> privilege.

Ah, so that's the bug, then.  Emacs does not know that OS X is
case-insensitive and it doesn't have code to special-case it as it
does for MS Windows.

> If OS X filesystems are always case-insensitive, perhaps the same code
> should also be compiled on that system.  If some of OS X filesystems
> are case-sensitive, we can only do that if Emacs can know which one is
> it.

That sounds right to me.

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Keith David Bershatsky]

The first available option used by "Disk Utility.app" is "Mac OS Extended (Journaled)".  I believe that is the format that comes shipped with new computers from Apple.  Other formats listed in the drop-down menu in Disk Utility are:  "Mac OS Extended"; "Mac OS Extended (Case-sensitive, Journaled)"; "Mac OS Extended (Case-sensitive)"; and two non-OSX options:  "MS-DOS (FAT)" and "ExFAT".

Some people probably use the Case-sensitive options for custom setups; however, I have no knowledge/experience in that regard.

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Mon, 04 Jan 2016 17:46:17 +0200,
Eli Zaretskii wrote:
> 
> * * *
> 
> If OS X filesystems are always case-insensitive, perhaps the same code
> should also be compiled on that system.  If some of OS X filesystems
> are case-sensitive, we can only do that if Emacs can know which one is
> it.

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Eli Zaretskii]

> Date:  Mon, 04 Jan 2016 09:41:15 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  22300@debbugs.gnu.org
> 
> The first available option used by "Disk Utility.app" is "Mac OS Extended (Journaled)".  I believe that is the format that comes shipped with new computers from Apple.  Other formats listed in the drop-down menu in Disk Utility are:  "Mac OS Extended"; "Mac OS Extended (Case-sensitive, Journaled)"; "Mac OS Extended (Case-sensitive)"; and two non-OSX options:  "MS-DOS (FAT)" and "ExFAT".
> 
> Some people probably use the Case-sensitive options for custom setups; however, I have no knowledge/experience in that regard.

Sorry, I know nothing about OS X -- how is "Disk Utility.app" related
to the issue at hand?

And if you are saying that some filesystems are case-insensitive, but
others aren't, we will need a function to tell whether a filesystem to
which the original file belongs is case-insensitive or not.

Thanks.

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> If OS X filesystems are always case-insensitive, perhaps the same code
> should also be compiled on that system. If some of OS X filesystems are
> case-sensitive, we can only do that if Emacs can know which one is it.

The boot filesystem must be case-insensitive, but HFS+ allows formatting a
drive as case-sensitive on non-boot volumes, so we can't assume OS X = case
insensitive. (I also use ZFS on the Mac, which can be case sensitive or
insensitive).

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Drew Adams]

If it turns out that Emacs cannot get the right info about this
automatically, how about adding a user option, so a user can at
least tell Emacs whether the OS treats file/folder names
case-sensitively?  The option doc would say that it applies only
for an OS where different behaviors are possible.

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Drew Adams <drew.adams@oracle.com>,  22300@debbugs.gnu.org,  esq@lawlist.com
> Date: Mon, 04 Jan 2016 11:22:57 -0800
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If OS X filesystems are always case-insensitive, perhaps the same code
> > should also be compiled on that system. If some of OS X filesystems are
> > case-sensitive, we can only do that if Emacs can know which one is it.
> 
> The boot filesystem must be case-insensitive, but HFS+ allows formatting a
> drive as case-sensitive on non-boot volumes, so we can't assume OS X = case
> insensitive. (I also use ZFS on the Mac, which can be case sensitive or
> insensitive).

Is there a C-callable API that could establish which one is it?
Something like the Posix 'pathconf', perhaps, with some magic
_PC_something argument?

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Eli Zaretskii]

> Date: Mon, 4 Jan 2016 11:27:34 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 22300@debbugs.gnu.org, esq@lawlist.com
> 
> If it turns out that Emacs cannot get the right info about this
> automatically, how about adding a user option, so a user can at
> least tell Emacs whether the OS treats file/folder names
> case-sensitively?

It's not a single value, the value can be different for each volume.

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Keith David Bershatsky]

Thank you, John, for helping me answer Eli's question about situations when OSX uses case-insensitive versus case-sensitive.  I didn't have the knowledge to be able to respond properly.

Here is an unsophisticated workaround that bypasses `dired-create-files' when dealing with renaming when (1) 'darwin; (2) just one file; and, (3) the file names of to/from are equal if both are lower-cased.  It doesn't do the fancy cutting/pasting of the new line in dired-mode and instead just reverts the entire buffer.

    (require 'dired-aux)

    (require 'cl) ;; for `lexical-let*'
    
    (defun dired-do-create-files (op-symbol file-creator operation arg
    					&optional marker-char op1
    					how-to)
      "Create a new file for each marked file.
    Prompt user for a target directory in which to create the new
      files.  The target may also be a non-directory file, if only
      one file is marked.  The initial suggestion for target is the
      Dired buffer's current directory (or, if `dired-dwim-target' is
      non-nil, the current directory of a neighboring Dired window).
    OP-SYMBOL is the symbol for the operation.  Function `dired-mark-pop-up'
      will determine whether pop-ups are appropriate for this OP-SYMBOL.
    FILE-CREATOR and OPERATION as in `dired-create-files'.
    ARG as in `dired-get-marked-files'.
    Optional arg MARKER-CHAR as in `dired-create-files'.
    Optional arg OP1 is an alternate form for OPERATION if there is
      only one file.
    Optional arg HOW-TO determines how to treat the target.
      If HOW-TO is nil, use `file-directory-p' to determine if the
       target is a directory.  If so, the marked file(s) are created
       inside that directory.  Otherwise, the target is a plain file;
       an error is raised unless there is exactly one marked file.
      If HOW-TO is t, target is always treated as a plain file.
      Otherwise, HOW-TO should be a function of one argument, TARGET.
       If its return value is nil, TARGET is regarded as a plain file.
       If it return value is a list, TARGET is a generalized
        directory (e.g. some sort of archive).  The first element of
        this list must be a function with at least four arguments:
          operation - as OPERATION above.
          rfn-list  - list of the relative names for the marked files.
          fn-list   - list of the absolute names for the marked files.
          target    - the name of the target itself.
          The rest of into-dir are optional arguments.
       For any other return value, TARGET is treated as a directory."
      (or op1 (setq op1 operation))
      (let* ((fn-list (dired-get-marked-files nil arg))
    	 (rfn-list (mapcar (function dired-make-relative) fn-list))
    	 (dired-one-file	; fluid variable inside dired-create-files
    	  (and (consp fn-list) (null (cdr fn-list)) (car fn-list)))
    	 (target-dir (dired-dwim-target-directory))
    	 (default (and dired-one-file
    		       (expand-file-name (file-name-nondirectory (car fn-list))
    					 target-dir)))
    	 (defaults (dired-dwim-target-defaults fn-list target-dir))
    	 (target (expand-file-name ; fluid variable inside dired-create-files
    		  (minibuffer-with-setup-hook
    		      (lambda ()
    			(set (make-local-variable 'minibuffer-default-add-function) nil)
    			(setq minibuffer-default defaults))
    		    (dired-mark-read-file-name
    		     (concat (if dired-one-file op1 operation) " %s to: ")
    		     target-dir op-symbol arg rfn-list default))))
    	 (into-dir (cond ((null how-to)
    			  ;; Allow DOS/Windows users to change the letter
    			  ;; case of a directory.  If we don't test these
    			  ;; conditions up front, file-directory-p below
    			  ;; will return t because the filesystem is
    			  ;; case-insensitive, and Emacs will try to move
    			  ;; foo -> foo/foo, which fails.
    			  (if (and (memq system-type '(ms-dos windows-nt cygwin))
    				   (eq op-symbol 'move)
    				   dired-one-file
    				   (string= (downcase
    					     (expand-file-name (car fn-list)))
    					    (downcase
    					     (expand-file-name target)))
    				   (not (string=
    					 (file-name-nondirectory (car fn-list))
    					 (file-name-nondirectory target))))
    			      nil
    			    (file-directory-p target)))
    			 ((eq how-to t) nil)
    			 (t (funcall how-to target)))))
        (if (and (consp into-dir) (functionp (car into-dir)))
    	(apply (car into-dir) operation rfn-list fn-list target (cdr into-dir))
          (if (not (or dired-one-file into-dir))
    	  (error "Marked %s: target must be a directory: %s" operation target))
          ;; rename-file bombs when moving directories unless we do this:
          (or into-dir (setq target (directory-file-name target)))
    ;;; BEGIN modification by @lawlist
          (if
              (and
                (eq system-type 'darwin)
                dired-one-file
                (equal op1 "Rename")
                (equal operation "Move")
                (equal (downcase (expand-file-name dired-one-file)) (downcase (expand-file-name target))))
            ;; Penetrate the `set-process-sentinel' with `lexical-let'.
            (lexical-let* ((dired-one-file dired-one-file)
                           (target target))
              (set-process-sentinel
                (start-process "rename" nil "mv" dired-one-file target)
                (lambda (p e) (when (= 0 (process-exit-status p))
                  (revert-buffer)
                  (message "Renamed %s to %s" dired-one-file target)))))
          (dired-create-files
           file-creator operation fn-list
           (if into-dir			; target is a directory
    	   ;; This function uses fluid variable target when called
    	   ;; inside dired-create-files:
    	   (function
    	    (lambda (from)
    	      (expand-file-name (file-name-nondirectory from) target)))
    	 (function (lambda (_from) target)))
           marker-char))
    ;;; END modification by @lawlist
      )))

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> Is there a C-callable API that could establish which one is it? Something
> like the Posix 'pathconf', perhaps, with some magic _PC_something argument?

It looks like getattrlist(2) is what you need:

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/getattrlist.2.html

Specifically, the volume attribute VOL_CAP_FMT_CASE_SENSITIVE.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Eli Zaretskii]

> Date:  Mon, 04 Jan 2016 11:45:22 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  22300@debbugs.gnu.org,John Wiegley <jwiegley@gmail.com>,Drew Adams <drew.adams@oracle.com>
> 
> Here is an unsophisticated workaround that bypasses `dired-create-files' when dealing with renaming when (1) 'darwin; (2) just one file; and, (3) the file names of to/from are equal if both are lower-cased.  It doesn't do the fancy cutting/pasting of the new line in dired-mode and instead just reverts the entire buffer.

I have 2 problems with this change:

  . it's IMO wrong to fix this on Dired level, it should be fixed on
    the rename-file level

  . when the filesystem is case-sensitive, the code should work like
    it does today, because then 'foo' and 'FOO' and 'Foo' are all
    different files

Thanks.

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: drew.adams@oracle.com,  22300@debbugs.gnu.org,  esq@lawlist.com
> Date: Mon, 04 Jan 2016 11:48:57 -0800
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Is there a C-callable API that could establish which one is it? Something
> > like the Posix 'pathconf', perhaps, with some magic _PC_something argument?
> 
> It looks like getattrlist(2) is what you need:
> 
> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/getattrlist.2.html
> 
> Specifically, the volume attribute VOL_CAP_FMT_CASE_SENSITIVE.

Thanks.  Patches are welcome to use this in rename-file.  I would
suggest a Darwin-specific version of string-equal that would compare
case-insensitively or case-sensitively as the volume requires that.
Then we could call that function from rename-file, like we do with
string-equal in the DOS_NT part there.

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Keith David Bershatsky]

I agree that `rename-file` could use a fix.

Once `rename-file` is ironed out on the C-source code level, I believe the tail end of `dired-do-create-files` will also need to be fixed because the `name-constructor`

(function (lambda (from) (expand-file-name (file-name-nondirectory from) target)))

returns the wrong path when used by dired-create-files.  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22300#29

So, I believe it will be both areas of Emacs that need some TLC.

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Mon, 04 Jan 2016 22:24:43 +0200,
Eli Zaretskii wrote:
> 
>  * * *
> 
> I have 2 problems with this change:
> 
>   . it's IMO wrong to fix this on Dired level, it should be fixed on
>     the rename-file level
> 
>   . when the filesystem is case-sensitive, the code should work like
>     it does today, because then 'foo' and 'FOO' and 'Foo' are all
>     different files
> 
> Thanks.

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Eli Zaretskii]

> Date:  Mon, 04 Jan 2016 12:51:01 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  22300@debbugs.gnu.org,Drew Adams <drew.adams@oracle.com>,John Wiegley <jwiegley@gmail.com>
> 
> I agree that `rename-file` could use a fix.
> 
> Once `rename-file` is ironed out on the C-source code level, I believe the tail 
> end of `dired-do-create-files` will also need to be fixed because the 
> `name-constructor`
> 
> (function (lambda (from) (expand-file-name (file-name-nondirectory from) 
> target)))
> 
> returns the wrong path when used by dired-create-files.  
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22300#29

Why do you think the result of that is wrong?  I think it's exactly as
expected, because this:

  (expand-file-name "SOMETHING" "/Users/HOME/Desktop/foo")

should produce "/Users/HOME/Desktop/foo/SOMETHING" for _any_ value of
SOMETHING, even if SOMETHING is exactly "foo", in the same letter-case
as the last component of "/Users/HOME/Desktop/foo".  That's what
expand-file-name does -- it produces a file name in the directory that
is its 2nd argument.

> So, I believe it will be both areas of Emacs that need some TLC.

There's already code in dired-create-files that handles the same
problem for MS-Windows and MS-DOS, it just needs to be reused for OS
X.  The tricky part with OS X is that its filesystems are not always
case-insensitive, so we need (a) a way to tell whether the filesystem
of the file being renamed is case-insensitive, and (b) tweak that code
a bit to use the above test instead of just testing the OS type.

In any case, invoking 'mv' as a workaround sounds not very clean to
me.  Emacs ought to do whatever 'mv' does to handle this problem by
itself.

I cannot produce a patch for these issues, as I don't have access to
OS X and the man page that John pointed to indicates that calling
getattrlist needs some non-trivial code (the API might not be
supported by the OS, and if it does, the specific attributes might not
be supported, so the code will have to include some reasonable
fallbacks).  So the code will need quite a bit of testing before it
becomes reliable enough to commit to the repository.  I hope someone
with good access to OS X will be able to come up with the changes and
test them.

Thanks.

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Keith David Bershatsky]

Actually, I'm not sure why the `elisp` makes the target "/Users/HOME/Desktop/foo/FOO", instead of just "/Users/HOME/Desktop/foo".

When I evaluate

  (funcall (lambda (from) (expand-file-name (file-name-nondirectory from) "/Users/HOME/Desktop/foo" )) "/Users/HOME/Desktop/FOO")

I get the former incorrect value -- i.e., "/Users/HOME/Desktop/foo/FOO", instead of just "/Users/HOME/Desktop/foo".

And that becomes the initial value of "to" when used by `dired-create-files` -- (setq to (funcall name-constructor from))

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Tue, 05 Jan 2016 18:46:00 +0200,
Eli Zaretskii wrote:
> 
> 
> Why do you think the result of that is wrong?  I think it's exactly as
> expected, because this:
> 
>   (expand-file-name "SOMETHING" "/Users/HOME/Desktop/foo")
> 
> should produce "/Users/HOME/Desktop/foo/SOMETHING" for _any_ value of
> SOMETHING, even if SOMETHING is exactly "foo", in the same letter-case
> as the last component of "/Users/HOME/Desktop/foo".  That's what
> expand-file-name does -- it produces a file name in the directory that
> is its 2nd argument.

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Eli Zaretskii]

> Date:  Tue, 05 Jan 2016 09:27:03 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  22300@debbugs.gnu.org,Drew Adams <drew.adams@oracle.com>,John Wiegley <jwiegley@gmail.com>
> 
> Actually, I'm not sure why the `elisp` makes the target "/Users/HOME/Desktop/foo/FOO", instead of just "/Users/HOME/Desktop/foo".
> 
> When I evaluate
> 
>   (funcall (lambda (from) (expand-file-name (file-name-nondirectory from) "/Users/HOME/Desktop/foo" )) "/Users/HOME/Desktop/FOO")
> 
> I get the former incorrect value -- i.e., "/Users/HOME/Desktop/foo/FOO", instead of just "/Users/HOME/Desktop/foo".

Maybe there's some misunderstanding here.  Let me explain why I think
this is the correct expected result.

First, (file-name-nondirectory "/Users/HOME/Desktop/FOO") yields
"FOO", as it should, right?

Then (expand-file-name "FOO" "/Users/HOME/Desktop/foo") returns
"/Users/HOME/Desktop/foo/FOO" because that's what it's supposed to do:
it returns a file named "FOO" in the directory "/Users/HOME/Desktop/foo".

Can you tell what in this reasoning seems incorrect, and why?

> And that becomes the initial value of "to" when used by `dired-create-files` -- (setq to (funcall name-constructor from))

The code that special-cases MS-Windows and MS-DOS prevents this from
causing the unexpected results.

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Keith David Bershatsky]

Perhaps my misunderstanding stems from a belief that "/Users/HOME/Desktop/foo/FOO" is a bad thing (to have as a result) when `dired-create-files` runs `(setq to (funcall name-constructor from))`.  I was looking at this as a black and white situation -- i.e., `from` is "/Users/HOME/Desktop/FOO"; and, `to` should be "/Users/HOME/Desktop/foo".

Because I do not understand the usefulness of "/Users/HOME/Desktop/foo/FOO" (when the user had explicitly entered a new name of "/Users/HOME/Desktop/foo"), I was expecting `(setq to (funcall name-constructor from))` to return "/Users/HOME/Desktop/foo" in this particular situation.

If I am understanding you correctly, you believe that "/Users/HOME/Desktop/foo/FOO" is a good thing at this point in the `elisp` code -- to be dealt with further on down when `dired-create-files` does its thing (with the assistance of some C-source code stuff under the hood).

From my layman's perspective (i.e., not a programmer by trade), I was thinking that `(setq to (funcall name-constructor from))` should yield the absolute path of what the user explicitly entered as the new name for the folder or file.  I had assumed, perhaps erroneously, that things would go awry rather quickly if the value of "to" was incorrect at the outset of `dired-create-files`.

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Tue, 05 Jan 2016 20:28:21 +0200,
Eli Zaretskii wrote:
> 
>  Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
> 
> > Date:  Tue, 05 Jan 2016 09:27:03 -0800
> > From:  Keith David Bershatsky <esq@lawlist.com>
> > Cc:  22300@debbugs.gnu.org,Drew Adams <drew.adams@oracle.com>,John Wiegley <jwiegley@gmail.com>
> > 
> > Actually, I'm not sure why the `elisp` makes the target "/Users/HOME/Desktop/foo/FOO", instead of just "/Users/HOME/Desktop/foo".
> > 
> > When I evaluate
> > 
> >   (funcall (lambda (from) (expand-file-name (file-name-nondirectory from) "/Users/HOME/Desktop/foo" )) "/Users/HOME/Desktop/FOO")
> > 
> > I get the former incorrect value -- i.e., "/Users/HOME/Desktop/foo/FOO", instead of just "/Users/HOME/Desktop/foo".
> 
> Maybe there's some misunderstanding here.  Let me explain why I think
> this is the correct expected result.
> 
> First, (file-name-nondirectory "/Users/HOME/Desktop/FOO") yields
> "FOO", as it should, right?
> 
> Then (expand-file-name "FOO" "/Users/HOME/Desktop/foo") returns
> "/Users/HOME/Desktop/foo/FOO" because that's what it's supposed to do:
> it returns a file named "FOO" in the directory "/Users/HOME/Desktop/foo".
> 
> Can you tell what in this reasoning seems incorrect, and why?
> 
> > And that becomes the initial value of "to" when used by `dired-create-files` -- (setq to (funcall name-constructor from))
> 
> The code that special-cases MS-Windows and MS-DOS prevents this from
> causing the unexpected results.

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Eli Zaretskii]

> Date:  Tue, 05 Jan 2016 19:56:35 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  22300@debbugs.gnu.org,Drew Adams <drew.adams@oracle.com>,John Wiegley <jwiegley@gmail.com>
> 
> Perhaps my misunderstanding stems from a belief that 
> "/Users/HOME/Desktop/foo/FOO" is a bad thing (to have as a result) when 
> `dired-create-files` runs `(setq to (funcall name-constructor from))`.  I was 
> looking at this as a black and white situation -- i.e., `from` is 
> "/Users/HOME/Desktop/FOO"; and, `to` should be "/Users/HOME/Desktop/foo".

We agree about that, I think.  However, what you actually wrote was
that you thought the result of expand-file-name in this case was
incorrect.  But expand-file-name and file-name-nondirectory are
general-purpose functions, they do nothing specific to Dired, and
their result in this case is correct and expected.  It's the code that
calls them that needs to be fixed, see below.

> Because I do not understand the usefulness of "/Users/HOME/Desktop/foo/FOO" 
> (when the user had explicitly entered a new name of "/Users/HOME/Desktop/foo"), 
> I was expecting `(setq to (funcall name-constructor from))` to return 
> "/Users/HOME/Desktop/foo" in this particular situation.

The logic of dired-do-rename in this case is very simple, and it
mimics the logic of the 'mv' command when its argument is a
directory.  When given the command "mv foo bar", it does this:

  . if the target 'bar' is an existing directory, it moves 'foo' to be
    a subdirectory of 'bar', i.e. 'foo' will become 'bar/foo'

  . otherwise, 'foo' is renamed to the new name 'bar'

What happens on case-insensitive filesystems is that when 'foo'
exists, so does 'FOO' and 'Foo' and 'fOO'.  So the above logic decides
that the target is an existing directory, and attempts to move 'foo'
into itself, which fails.  So it's that logic which needs to be
augmented for case-insensitive filesystems.  But the place to augment
it is not where we compute 'foo/bar' (or in this case 'foo/FOO'), the
place is where the logic decides which of the above two alternatives
to take.

This same logic is implemented both in Dired and in rename-file, so it
should be augmented in both of these places.  As we've done for
MS-Windows and MS-DOS.

> If I am understanding you correctly, you believe that 
> "/Users/HOME/Desktop/foo/FOO" is a good thing at this point in the `elisp` code 
> -- to be dealt with further on down when `dired-create-files` does its thing 
> (with the assistance of some C-source code stuff under the hood).

No, the logic that should be augmented is in dired-do-create-files,
and it happens _before_ dired-create-files is called.  By the time
dired-create-files is called it's too late, because
dired-do-create-files already decided which of the above 2
alternatives to use.  Look at the source of dired-do-create-files, and
you will see code in dired-do-create-files that special-cases
MS-Windows to augment the logic.

> From my layman's perspective (i.e., not a programmer by trade), I was thinking 
> that `(setq to (funcall name-constructor from))` should yield the absolute path 
> of what the user explicitly entered as the new name for the folder or file.  I 
> had assumed, perhaps erroneously, that things would go awry rather quickly if 
> the value of "to" was incorrect at the outset of `dired-create-files`.

The logic to which I alluded above takes care of that: it calls
dired-create-files with a different name-constructor function, which
does what you want:

      (dired-create-files
       file-creator operation fn-list
       (if into-dir			; target is a directory
	   ;; This function uses fluid variable target when called
	   ;; inside dired-create-files:
	   (function
	    (lambda (from)
	      (expand-file-name (file-name-nondirectory from) target)))
	 (function (lambda (_from) target)))
       marker-char)

Which name-constructor function is passed to dired-create-files
depends on the value of into-dir.  The special-case code for
MS-Windows takes care of making that value nil, so that the
constructor which produces "incorrect" file name is not called by
dired-create-files.

To summarize: there is already code in dired-do-create-files that will
DTRT in this case for case-insensitive filesystems.  It just needs to
be invoked on OS X when the underlying filesystem is case-insensitive,
and the only problem preventing us from fixing this is that we don't
yet have a way to tell that on OS X as we do on other systems.

IOW, all it takes to fix this is to write an OS X specific predicate
function that would accept a file name and returns and indication
whether that file lives on a case-insensitive filesystem.  Then we
should just use that function in Dired and in rename-file.

bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.

[Keith David Bershatsky]

Thank you, Eli, for walking me through the `elisp` portions of the code.  When the feature #22300 is implemented, I'll take a look at the new tail end of `dired-do-create-files' to see how the new situation will be handled.

Your helpful teaching/mentoring is greatly appreciated!

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Wed, 06 Jan 2016 17:40:45 +0200,
Eli Zaretskii wrote:
> 
>  * * *
> 
> IOW, all it takes to fix this is to write an OS X specific predicate
> function that would accept a file name and returns and indication
> whether that file lives on a case-insensitive filesystem.  Then we
> should just use that function in Dired and in rename-file.