* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-03 20:57 bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase Keith David Bershatsky
@ 2016-01-03 21:10 ` John Wiegley
2016-01-04 0:47 ` Drew Adams
2016-01-04 3:31 ` Eli Zaretskii
` (7 subsequent siblings)
8 siblings, 1 reply; 29+ messages in thread
From: John Wiegley @ 2016-01-03 21:10 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 22300-done
>>>>> 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
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-03 21:10 ` John Wiegley
@ 2016-01-04 0:47 ` Drew Adams
2016-01-04 1:11 ` John Wiegley
2016-01-04 15:44 ` Eli Zaretskii
0 siblings, 2 replies; 29+ messages in thread
From: Drew Adams @ 2016-01-04 0:47 UTC (permalink / raw)
To: John Wiegley, Keith David Bershatsky; +Cc: 22300-done
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-04 0:47 ` Drew Adams
@ 2016-01-04 1:11 ` John Wiegley
2016-01-04 1:37 ` Drew Adams
2016-01-04 15:44 ` Eli Zaretskii
1 sibling, 1 reply; 29+ messages in thread
From: John Wiegley @ 2016-01-04 1:11 UTC (permalink / raw)
To: Drew Adams; +Cc: 22300-done, Keith David Bershatsky
>>>>> 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
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-04 1:11 ` John Wiegley
@ 2016-01-04 1:37 ` Drew Adams
2016-01-04 15:46 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: Drew Adams @ 2016-01-04 1:37 UTC (permalink / raw)
To: John Wiegley; +Cc: 22300-done, Keith David Bershatsky
> > 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-04 1:37 ` Drew Adams
@ 2016-01-04 15:46 ` Eli Zaretskii
2016-01-04 16:15 ` Drew Adams
2016-01-04 19:22 ` John Wiegley
0 siblings, 2 replies; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-04 15:46 UTC (permalink / raw)
To: Drew Adams; +Cc: 22300, jwiegley, esq
> 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-04 15:46 ` Eli Zaretskii
@ 2016-01-04 16:15 ` Drew Adams
2016-01-04 19:22 ` John Wiegley
1 sibling, 0 replies; 29+ messages in thread
From: Drew Adams @ 2016-01-04 16:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22300, jwiegley, esq
> > 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-04 15:46 ` Eli Zaretskii
2016-01-04 16:15 ` Drew Adams
@ 2016-01-04 19:22 ` John Wiegley
2016-01-04 19:27 ` Drew Adams
2016-01-04 19:44 ` Eli Zaretskii
1 sibling, 2 replies; 29+ messages in thread
From: John Wiegley @ 2016-01-04 19:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22300, esq
>>>>> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-04 19:22 ` John Wiegley
@ 2016-01-04 19:27 ` Drew Adams
2016-01-04 19:45 ` Eli Zaretskii
2016-01-04 19:44 ` Eli Zaretskii
1 sibling, 1 reply; 29+ messages in thread
From: Drew Adams @ 2016-01-04 19:27 UTC (permalink / raw)
To: John Wiegley, Eli Zaretskii; +Cc: 22300, esq
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-04 19:27 ` Drew Adams
@ 2016-01-04 19:45 ` Eli Zaretskii
0 siblings, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-04 19:45 UTC (permalink / raw)
To: Drew Adams; +Cc: 22300, jwiegley, esq
> 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-04 19:22 ` John Wiegley
2016-01-04 19:27 ` Drew Adams
@ 2016-01-04 19:44 ` Eli Zaretskii
2016-01-04 19:48 ` John Wiegley
1 sibling, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-04 19:44 UTC (permalink / raw)
To: John Wiegley; +Cc: 22300, esq
> 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?
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-04 19:44 ` Eli Zaretskii
@ 2016-01-04 19:48 ` John Wiegley
2016-01-04 20:31 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: John Wiegley @ 2016-01-04 19:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22300, esq
>>>>> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-04 19:48 ` John Wiegley
@ 2016-01-04 20:31 ` Eli Zaretskii
0 siblings, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-04 20:31 UTC (permalink / raw)
To: John Wiegley; +Cc: 22300, esq
> 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-04 0:47 ` Drew Adams
2016-01-04 1:11 ` John Wiegley
@ 2016-01-04 15:44 ` Eli Zaretskii
1 sibling, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-04 15:44 UTC (permalink / raw)
To: Drew Adams; +Cc: 22300, jwiegley, esq
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-03 20:57 bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase Keith David Bershatsky
2016-01-03 21:10 ` John Wiegley
@ 2016-01-04 3:31 ` Eli Zaretskii
2016-01-04 4:19 ` Keith David Bershatsky
` (6 subsequent siblings)
8 siblings, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-04 3:31 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 22300
> 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?
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-03 20:57 bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase Keith David Bershatsky
2016-01-03 21:10 ` John Wiegley
2016-01-04 3:31 ` Eli Zaretskii
@ 2016-01-04 4:19 ` Keith David Bershatsky
2016-01-04 15:50 ` Eli Zaretskii
2016-01-04 17:41 ` Keith David Bershatsky
` (5 subsequent siblings)
8 siblings, 1 reply; 29+ messages in thread
From: Keith David Bershatsky @ 2016-01-04 4:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22300, John Wiegley
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?
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-04 4:19 ` Keith David Bershatsky
@ 2016-01-04 15:50 ` Eli Zaretskii
0 siblings, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-04 15:50 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 22300, jwiegley
> 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-03 20:57 bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase Keith David Bershatsky
` (2 preceding siblings ...)
2016-01-04 4:19 ` Keith David Bershatsky
@ 2016-01-04 17:41 ` Keith David Bershatsky
2016-01-04 19:12 ` Eli Zaretskii
2016-01-04 19:45 ` Keith David Bershatsky
` (4 subsequent siblings)
8 siblings, 1 reply; 29+ messages in thread
From: Keith David Bershatsky @ 2016-01-04 17:41 UTC (permalink / raw)
To: Eli Zaretskii, Drew Adams, John Wiegley; +Cc: 22300
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.
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-04 17:41 ` Keith David Bershatsky
@ 2016-01-04 19:12 ` Eli Zaretskii
0 siblings, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-04 19:12 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 22300, jwiegley
> 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-03 20:57 bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase Keith David Bershatsky
` (3 preceding siblings ...)
2016-01-04 17:41 ` Keith David Bershatsky
@ 2016-01-04 19:45 ` Keith David Bershatsky
2016-01-04 20:24 ` Eli Zaretskii
2016-01-04 20:51 ` Keith David Bershatsky
` (3 subsequent siblings)
8 siblings, 1 reply; 29+ messages in thread
From: Keith David Bershatsky @ 2016-01-04 19:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22300, John Wiegley
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
)))
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-04 19:45 ` Keith David Bershatsky
@ 2016-01-04 20:24 ` Eli Zaretskii
0 siblings, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-04 20:24 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 22300, jwiegley
> 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-03 20:57 bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase Keith David Bershatsky
` (4 preceding siblings ...)
2016-01-04 19:45 ` Keith David Bershatsky
@ 2016-01-04 20:51 ` Keith David Bershatsky
2016-01-05 16:46 ` Eli Zaretskii
2016-01-05 17:27 ` Keith David Bershatsky
` (2 subsequent siblings)
8 siblings, 1 reply; 29+ messages in thread
From: Keith David Bershatsky @ 2016-01-04 20:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22300, John Wiegley
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.
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-04 20:51 ` Keith David Bershatsky
@ 2016-01-05 16:46 ` Eli Zaretskii
0 siblings, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-05 16:46 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 22300, jwiegley
> 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-03 20:57 bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase Keith David Bershatsky
` (5 preceding siblings ...)
2016-01-04 20:51 ` Keith David Bershatsky
@ 2016-01-05 17:27 ` Keith David Bershatsky
2016-01-05 18:28 ` Eli Zaretskii
2016-01-06 3:56 ` Keith David Bershatsky
2016-01-06 19:57 ` Keith David Bershatsky
8 siblings, 1 reply; 29+ messages in thread
From: Keith David Bershatsky @ 2016-01-05 17:27 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22300, John Wiegley
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.
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-05 17:27 ` Keith David Bershatsky
@ 2016-01-05 18:28 ` Eli Zaretskii
0 siblings, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-05 18:28 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 22300, jwiegley
> 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-03 20:57 bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase Keith David Bershatsky
` (6 preceding siblings ...)
2016-01-05 17:27 ` Keith David Bershatsky
@ 2016-01-06 3:56 ` Keith David Bershatsky
2016-01-06 15:40 ` Eli Zaretskii
2016-01-06 19:57 ` Keith David Bershatsky
8 siblings, 1 reply; 29+ messages in thread
From: Keith David Bershatsky @ 2016-01-06 3:56 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22300, John Wiegley
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.
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-06 3:56 ` Keith David Bershatsky
@ 2016-01-06 15:40 ` Eli Zaretskii
0 siblings, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2016-01-06 15:40 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 22300, jwiegley
> 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase.
2016-01-03 20:57 bug#22300: 25.1.50; Dired -- renaming folders/files to CamelCase/UPPERCASE/lowercase Keith David Bershatsky
` (7 preceding siblings ...)
2016-01-06 3:56 ` Keith David Bershatsky
@ 2016-01-06 19:57 ` Keith David Bershatsky
8 siblings, 0 replies; 29+ messages in thread
From: Keith David Bershatsky @ 2016-01-06 19:57 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22300, John Wiegley
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.
^ permalink raw reply [flat|nested] 29+ messages in thread