Better support of same name different case folders

[DrShark]

On my Vista PC one of the folders that belong to antivirus has subfolders with different config files of that antivirus. Two of that subfolders have the same name, but different case:
folder\qb\
folder\QB\
The only difference of that subfolders is their modification date (tc.writedate), the files in both subfolders are the same.

My Windows doesn't have enabled the option to use same name different case for files in one folder, so probably antivirus made this second same name subfolder writing directly to $MFT.
Anyway, for such folders the things I'd like to see improved in TC are:
1. Explorer shows full context menu for such folders and files that are inside of these folders, TC shows limited own one with only following items available:

Code: Select all

internal associations items
---------------------
[name] (aka open)
---------------------
Copy...
Move...
Create Shortcut
Delete
---------------------
Properties

In TC Properties menu doesn't work (does nothing) while in Explorer it shows folder or file Properties dialog. Also, in Explorer some menu items created by 3rd party extensions work for such folders and files inside.
So I'd like to see in TC full menu for mentioned folders and files, or at least working Properties item in current simplified TC's menu.

2. The only way to pack such folders using Commander's internal packers is to use TAR or TAR.GZ. TC, however, doesn't show second folder in panel when entering such archive, instead it shows all files of both folders in this one available folder inside.
I suggest, at least optional, to show all folders with same name and different case, and the number of files in each subfolder should be the same like on real file system source. Unpacking it sholud't be a problem if user will select both folders or whole archive to unpack: TC either will make only one folder and offer replace dialog for files (it as an Autorename option so user can put all files there), or even offer replace with dialog like for files but for folder when unpacking secon one (so use will have qb\ and qb(2)\ if will choose to autorename, with correct files inside each after unpacking).
Such archive sample available for download from here.
It has following folder\file tree:
qb\tsw.avz
qb\bt.avz
QB\tsw.avz
QB\bt.avz

[Stefan2]

The WindowsTM file system do not allow more than one file with one single name, even with different letter cases.

The $MFT is central part of that file system.


So what you see is probably something other.







 

[Dalai]

2Stefan2
That's not correct. NTFS definitely supports case-sensitive file names, but the shell (Explorer) does not! I'm not sure about the Windows API, but I guess this depends on whether or not case-sensitive behavior is enabled in the system.

Supporting case-sensitive file names would be a huge amount of work, and a mess, too. Even if TC would support it, most Windows programs don't, and this includes shell extensions, plugins and so on. In the end, it would be a complex thing to determine exactly where the culprit is if something doesn't work as expected.

Regards
Dalai

[Horst.Epp]

I think its time to change the Antivirus program and not to spend time in TC functions which no one needs in Windows.
I had many different Antivirus programs installed and none made such strange things in the file system.
Whats the tools which makes it ?

[Stefan2]

2Dalai ah, that way around? But I am still not sure, I will lockup that...



NTFS supports POSIX semantics for case sensitivity

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx

Naming Conventions

The following fundamental rules enable applications to create and process valid names for files and directories, regardless of the file system:

Do not assume case sensitivity. For example, consider the names OSCAR, Oscar, and oscar to be the same,
even though some file systems (such as a POSIX-compliant file system) may consider them as different.

Note that NTFS supports POSIX semantics for case sensitivity
but this is not the default behavior. For more information, see CreateFile.

CreateFile function

https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx

CreateFile function

FILE_FLAG_POSIX_SEMANTICS

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.

So if a application use the flag POSIX_SEMANTICS it can create files with same names but different case?

OK, fine, but not nice of them. And no reason for TC to support that behavior too, IMHO.


How can one access and delete such same name folders?
WinEx and TC both can handle that, DrShark?






 

[Dalai]

I will lockup that...

I hope you don't lock up while doing so .

So if a application use the flag POSIX_SEMANTICS it can create files with same names but different case?

I think that this only works when POSIX compatibility is enabled in the system, but I'm not sure. IIRC there's some GPO that sets a registry switch to do so.

And no reason for TC to support that behavior too, IMHO.

Yep, that's why I said it would be a mess. On Linux and other POSIX compatible systems this works OOTB because it has always been this way, and every software supports it.

How can one access and delete such same name folders?

Good question. If the API functions don't need POSIX compat. to be enabled in the system, it may just work by setting the appropriate flags in the functions. If they require POSIX compat. to be set, it may be set on DrShark's system.

Regards
Dalai

[ts4242]

Whats the tools which makes it ?

Kaspersky, i guess!

[DrShark]

There is no request for full support of such names, i.e. in all TC functions. Topic title says "better support", and topic body clearly shows what I ask for: 1) Explorer's context menu+properties dialog; 2) correct browsing of TAR archive with such folders and/or files.

Even if TC would support it, most Windows programs don't, and this includes shell extensions, plugins and so on. In the end, it would be a complex thing to determine exactly where the culprit is if something doesn't work as expected.

This argument about "most programs" is about nothing. If user have files/folders with such names (allowed on NTFS but not in Windows Explorer or CMD) then either one has special tools to work with such names or just want to store them on a hard drive for some reason (moving them later to other OS like Linux is only one possible reason).

edit: BTW TC 9 has some improvements in NTFS-only correct names handling, history.txt has some lines about this.

[milo1012]

First of all, two links regarding the case sensitivity capability/issue:
https://support.microsoft.com/en-us/help/100625/filenames-are-case-sensitive-on-ntfs-volumes
https://superuser.com/questions/266110/how-do-you-make-windows-7-fully-case-sensitive-with-respect-to-the-filesystem
And another one:
http://www.nicklowe.org/2012/02/understanding-case-sensitivity-in-windows-obcaseinsensitive-file_case_sensitive_search/
And to quote the latter:

At the Win32 environment subsystem, the only exposure to case sensitivity is for File objects and via the following APIs:
CreateFile / CreateFileTransacted
...
FindFirstFileEx / FindFirstFileTransacted
...

This means, all other functions won't support it, with the most important ones probably being DeleteFile(), CopyFileEx(), MoveFileEx().
This also means that, in order to work case sensitive, TC would need to access the NT Native API for many functions.

So I'd like to see in TC full menu for mentioned folders and files, or at least working Properties item in current simplified TC's menu.

I doubt that the full menu is available, due to many shell functions missing case sensitive support. But I agree that the properties should be available.

[Dalai]

Even if the full context menu would be available like in Explorer: How can you be sure to see the properties/entries of the correct file/directory? The file names shown in the context menu might be wrong, because case normally doesn't matter. So you might see the properties/attributes/whatever of the wrong file.

If only one piece of software in the chain you use doesn't support case-sensitive file names, you're out of luck. Example: Assuming TC would support it, but any shell extension or the context menu you use doesn't, you still won't be able to use the advantage because of some other software (and you might not even notice that). Also, how many people really require case sensivity? Are there enough that it's worth the effort? I don't think so, but the decision is up to Ghisler, of course. IIRC the topic of case sensitivity has been discussed before.

Regards
Dalai

[milo1012]

IIRC the topic of case sensitivity has been discussed before.

Indeed:

http://www.ghisler.ch/board/viewtopic.php?t=41026
(in German):
http://www.ghisler.ch/board/viewtopic.php?t=36168