won't rename if case change only, reports conflict

[markmarz]

Hi,

Running newly installed Windows Store app version of FileBot.

In this image https://1drv.ms/i/s!AljqkAEeGrs3gYIGMKnf9P_HvEDIXA
you can see an example where FileBot reports a conflict in a rename of 'A Blueprint For Murder (1953).mp4' to 'A Blueprint for Murder (1953).mp4', where the only difference is the case of 'for'.

Why is this a conflict and is there any way to override it? The Override button is grayed out. Also I'd like a global override anyway, if there isn't one already that I just can't find.

Thanks,
Mark Marziale

[rednoah]

Newer revisions (i.e. the next version) won't show a warning in this case. However, that may not really matter either way because the file is either ignored because of the "conflict" or because the source/destination filename is the same (according to Windows, which may ignore rename operations where only the letter-case is changed).


EDIT:

If you're processing files that are already well-named and/or have previously been processed by FileBot then your workflow is probably wrong/inefficient.

Set your format to something like X:/Media/{plex} and have FileBot move/organize files into a new folder structure. You won't ever have conflict-with-existing-files or changes-in-letter-case-only kind of issues. You'll also have a clear separation between well-named and not-well-named files which you will find very important at some point down the road.

[markmarz]

I'm running FileBot against some titles that I want to verify have filenames that match the Movie DB so there'll be a perfect match. The reason is that someone on the Plex forums has raised the possibility of Plex ignoring locked fields if the title is rematched. It seems easiest to just avoid that possibility by running through FileBot, whether or not Plex actually ignores locked fields.

The files actually exist on a Debian server, where case matters. A rename where there is only a case change works just fine on Debian. The fact that I'm going through a Samba share means FileBot sees the file as a Windows filename with Window peculiarities, but it's not really the case (pun! hah-hah!).

The way things are now, even if I move the files off the share into a local filesystem on Windows, FileBot still raises the conflict warning and won't change the filename. This is either a bug or poor design, since Windows does allow filename changes where only case is changed. Also I don't want to screw around moving files off the share in the first place.

When you say that the warnings won't be shown in the next version, does that mean that the rename will take place or that the rename will silently be ignored?

[rednoah]

When you say that the warnings won't be shown in the next version, does that mean that the rename will take place or that the rename will silently be ignored?

No more warnings, and I honestly don't know.

FileBot will ask Windows to move A to B (which is why you get the nice native Windows Move/Copy Dialog if things take a bit longer) but Windows may (or may not) do whatever it wants and ignore the operation.

If you use FileBot (console) then it'll work because the alternate configuration uses the Java NIO.2 API for file operations instead of the Windows Shell32 API.

[markmarz]

Okay, I'll try the console, but that's after the next version is released, right? I just tried the current release console version and the behavior is the same way as the non-console version. I'm looking forward to the warning logic getting the heck out of the way in the next version.

Strange that Windows is so darn unpredictable. I can easily change the case of a filename 'manually' using Windows explorer and I'd be amazed if I couldn't do it with Perl. So I don't get which cases fail.

[rednoah]

Yes, the solution has been implemented, but the next release probably won't be released until early next year.

PS: Explorer is special. Try it with Perl. It probably won't work. It doesn't work with Java, unless you set the ATOMIC_MOVE flag for some mysterious reason.

[markmarz]

Wow, Windows is always full of delightful surprises! Hah-hah! I definitely will try with Perl.

Thanks for your help, and thanks for FileBot.

[markmarz]

Interestingly, Perl does work on my setup (Windows 10):

Code: Select all

C:\perl_test>dir
 Volume in drive C is C
 Volume Serial Number is 0A8F-BA7E

 Directory of C:\perl_test

12/18/2016  02:18 PM    <DIR>          .
12/18/2016  02:18 PM    <DIR>          ..
12/18/2016  02:16 PM                75 test.pl
12/18/2016  02:08 PM                 0 TEST.txt
               2 File(s)             75 bytes
               2 Dir(s)  420,592,836,608 bytes free

C:\perl_test>type test.pl
use File::Copy;

move( "TEST.txt", "test.txt" ) or die "cannot move: $!";
C:\perl_test>perl --version

This is perl 5, version 24, subversion 0 (v5.24.0) built for MSWin32-x64-multi-thread

Copyright 1987-2016, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.

C:\perl_test>test.pl

C:\perl_test>dir
 Volume in drive C is C
 Volume Serial Number is 0A8F-BA7E

 Directory of C:\perl_test

12/18/2016  02:18 PM    <DIR>          .
12/18/2016  02:18 PM    <DIR>          ..
12/18/2016  02:16 PM                75 test.pl
12/18/2016  02:08 PM                 0 test.txt
               2 File(s)             75 bytes
               2 Dir(s)  420,592,836,608 bytes free
               

[mihawk90]

The problem is basically this:

Current Windows file systems, like NTFS, are case-sensitive; that is a readme.txt and a Readme.txt can exist in the same directory. However, the API for file access in Windows applications is case-insensitive, which makes filenames case-insensitive from the application's point of view. Therefore, applications only have access to one of the files whose filenames only differ in case, and some commands may fail if the filename provided is ambiguous

NTFS as a filesystem is case-sensitive. The Windows Explorer however is just an abstraction for the filesystem. You can rename a file from lower-case to upper-case, but you cannot create 2 files having just a case difference (e.g. test.txt and TEST.txt). Lower-level System tools will allow you to do that, but the Windows Explorer won't. It's pretty much going back to the DOS based days since some components of the NT Kernel are still on a DOS basis, which was case-insensitive.

Both PowerShell and CMD will let you rename in a case-sensitive manner now though. Perl probably works because it most likely uses the FILE_FLAG_POSIX_SEMANTICS on the Windows API level, which according to the documentation:

Access will occur according to POSIX rules. This includes allowing multiple files with names, differing only in case, for file systems that support that naming. Use care when using this option, because files created with this flag may not be accessible by applications that are written for MS-DOS or 16-bit Windows.

The question is just why are some (or all?) of the move operations done without that and if it's possible to set that flag within Java.


I suppose as a temporary solution you could do a 2-step rename for now. Rename the file adding an additional character (like an underscore) in the format string, then do a second rename with the same format string without the additional character. It should be recognized as a different name, therefore taking setting the new case.

[markmarz]

This is interesting, thanks. But doesn't the developer already have a solution without an intermediate rename? He has said that the case-sensitive rename works in the Java console version of FileBot and will be implemented in the next release. He will also remove the blocking logic that raises a warning.

[mihawk90]

Apparently I overread something, I understood that the warning is just being supressed, at least I understood the first reply as in "it may work, it may not"

[markmarz]

Well, it's equally possible I misread! Hah-hah! Maybe I'm hearing what I want to hear. I'll let the developer speak for himself. Thanks for your contribution, it's very interesting.

[rednoah]

Yeah, the GUI version uses the Shell32 Move/Copy dialog, and I seem to remember that it used ignore case-changes a while back. A newer Windows update may have fixed that though.

The pure Java implementation (used in the CLI) will always work.