When you ran "mv" there, it exited before even calling the rename() system call (I ran it through strace), so that could just be a bug in coreutils.
However, I just compiled a little test program (attached) and ran it through strace with some interesting results:
20:29:01 execve("./rename_file", ["./rename_file", "/media/disk/test", "/media/disk/Test"], [/* 38 vars */]) = 0 <0.012420> 20:29:01 brk(0) = 0x1880000 <0.000031> 20:29:01 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fad7a106000 <0.000038> 20:29:01 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) <0.002623> 20:29:01 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fad7a104000 <0.000029> 20:29:01 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) <0.000024> 20:29:01 open("/etc/ld.so.cache", O_RDONLY) = 3 <0.000038> 20:29:01 fstat(3, {st_mode=S_IFREG|0644, st_size=112556, ...}) = 0 <0.000019> 20:29:01 mmap(NULL, 112556, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fad7a0e8000 <0.000025> 20:29:01 close(3) = 0 <0.000020> 20:29:01 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) <0.000023> 20:29:01 open("/lib/libc.so.6", O_RDONLY) = 3 <0.000032> 20:29:01 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\345"..., 832) = 832 <0.000022> 20:29:01 fstat(3, {st_mode=S_IFREG|0755, st_size=1502520, ...}) = 0 <0.000018> 20:29:01 mmap(NULL, 3609304, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fad79b77000 <0.000024> 20:29:01 mprotect(0x7fad79ce0000, 2093056, PROT_NONE) = 0 <0.000040> 20:29:01 mmap(0x7fad79edf000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x168000) = 0x7fad79edf000 <0.000037> 20:29:01 mmap(0x7fad79ee4000, 17112, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fad79ee4000 <0.000027> 20:29:01 close(3) = 0 <0.000017> 20:29:01 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fad7a0e7000 <0.000023> 20:29:01 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fad7a0e6000 <0.000020> 20:29:01 arch_prctl(ARCH_SET_FS, 0x7fad7a0e66e0) = 0 <0.000018> 20:29:01 mprotect(0x7fad79edf000, 16384, PROT_READ) = 0 <0.000024> 20:29:01 mprotect(0x600000, 4096, PROT_READ) = 0 <0.000025> 20:29:01 mprotect(0x7fad7a107000, 4096, PROT_READ) = 0 <0.000023> 20:29:01 munmap(0x7fad7a0e8000, 112556) = 0 <0.000035> 20:29:01 rename("/media/disk/test", "/media/disk/Test") = 0 <0.000059> 20:29:01 exit_group(0) = ?
You'll notice that the rename() exits with success, but the filename never changed. So, there is a bug in the kernel.
When you ran "mv" there, it exited before even calling the rename() system call (I ran it through strace), so that could just be a bug in coreutils.
However, I just compiled a little test program (attached) and ran it through strace with some interesting results:
20:29:01 execve( "./rename_ file", ["./rename_file", "/media/disk/test", "/media/ disk/Test" ], [/* 38 vars */]) = 0 <0.012420> PROT_WRITE, MAP_PRIVATE| MAP_ANONYMOUS, -1, 0) = 0x7fad7a106000 <0.000038> "/etc/ld. so.nohwcap" , F_OK) = -1 ENOENT (No such file or directory) <0.002623> PROT_WRITE, MAP_PRIVATE| MAP_ANONYMOUS, -1, 0) = 0x7fad7a104000 <0.000029> "/etc/ld. so.preload" , R_OK) = -1 ENOENT (No such file or directory) <0.000024> etc/ld. so.cache" , O_RDONLY) = 3 <0.000038> S_IFREG| 0644, st_size=112556, ...}) = 0 <0.000019> "/etc/ld. so.nohwcap" , F_OK) = -1 ENOENT (No such file or directory) <0.000023> lib/libc. so.6", O_RDONLY) = 3 <0.000032> 2\1\1\0\ 0\0\0\0\ 0\0\0\0\ 3\0>\0\ 1\0\0\0\ 220\345" ..., 832) = 832 <0.000022> S_IFREG| 0755, st_size=1502520, ...}) = 0 <0.000018> PROT_EXEC, MAP_PRIVATE| MAP_DENYWRITE, 3, 0) = 0x7fad79b77000 <0.000024> 0x7fad79ce0000, 2093056, PROT_NONE) = 0 <0.000040> f000, 20480, PROT_READ| PROT_WRITE, MAP_PRIVATE| MAP_FIXED| MAP_DENYWRITE, 3, 0x168000) = 0x7fad79edf000 <0.000037> 4000, 17112, PROT_READ| PROT_WRITE, MAP_PRIVATE| MAP_FIXED| MAP_ANONYMOUS, -1, 0) = 0x7fad79ee4000 <0.000027> PROT_WRITE, MAP_PRIVATE| MAP_ANONYMOUS, -1, 0) = 0x7fad7a0e7000 <0.000023> PROT_WRITE, MAP_PRIVATE| MAP_ANONYMOUS, -1, 0) = 0x7fad7a0e6000 <0.000020> ARCH_SET_ FS, 0x7fad7a0e66e0) = 0 <0.000018> 0x7fad79edf000, 16384, PROT_READ) = 0 <0.000024> 0x7fad7a107000, 4096, PROT_READ) = 0 <0.000023> 0x7fad7a0e8000, 112556) = 0 <0.000035> "/media/ disk/test" , "/media/disk/Test") = 0 <0.000059>
20:29:01 brk(0) = 0x1880000 <0.000031>
20:29:01 mmap(NULL, 4096, PROT_READ|
20:29:01 access(
20:29:01 mmap(NULL, 8192, PROT_READ|
20:29:01 access(
20:29:01 open("/
20:29:01 fstat(3, {st_mode=
20:29:01 mmap(NULL, 112556, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fad7a0e8000 <0.000025>
20:29:01 close(3) = 0 <0.000020>
20:29:01 access(
20:29:01 open("/
20:29:01 read(3, "\177ELF\
20:29:01 fstat(3, {st_mode=
20:29:01 mmap(NULL, 3609304, PROT_READ|
20:29:01 mprotect(
20:29:01 mmap(0x7fad79ed
20:29:01 mmap(0x7fad79ee
20:29:01 close(3) = 0 <0.000017>
20:29:01 mmap(NULL, 4096, PROT_READ|
20:29:01 mmap(NULL, 4096, PROT_READ|
20:29:01 arch_prctl(
20:29:01 mprotect(
20:29:01 mprotect(0x600000, 4096, PROT_READ) = 0 <0.000025>
20:29:01 mprotect(
20:29:01 munmap(
20:29:01 rename(
20:29:01 exit_group(0) = ?
You'll notice that the rename() exits with success, but the filename never changed. So, there is a bug in the kernel.