DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:content-type:content-transfer-encoding; q=dns; s=default; b=A1d
	sBsYBlMjJZNPNjACnlUaTRTtBzo25LEw1lhmlpYLslgha9yfwHH8Q7sGK3/Un7Q/
	lMVn+HM8lk5SP5Q/HxPJfivbMZOxBf3GupUEPFbhwJyd4HIQv3LNj4sS8geiWtpq
	aXHAIyEqee/wvPNpGDg47Xp8TRESKAFiiSuIritA=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <51FB56D0.4040609@shaddybaddah.name>
Date: Fri, 02 Aug 2013 16:50:56 +1000
From: Shaddy Baddah <lithium-cygwin AT shaddybaddah DOT name>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130704 Icedove/17.0.7
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Case sensitive filenames for non-NTFS filesystems
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

As per:

http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive

Cygwin act on filenames on NTFS in with case preservation/sensitivity.

As this was a feature configured in the Windows kernel, the pre-existing
limitation whereby the same case sensitivity was not available for FAT32
was an understandable compromise.

Unfortunately, in providing EXFAT, Microsoft has not seen fit to carry
over the same handling in the kernel as it does in NTFS.

In my opinion, the knock on limitation in Cygwin for FAT32 was easy to
accept as it was quite inferior to NTFS. The limitation with EXFAT is a
little difficult to accept, and this is the motive behind this email.

I don't expect much interest in this suggestion, but make it here to at
least bring awareness to the problem.

Can I suggest that if it is a) feasible b) doable without too much added
degradation in performance/complexity to the file handling code, that
Cygwin add some limited support itself.

I'm not talking about going back to something like the old managed
mounts, but more to its replacement function. That being the same
handling of special characters like :, |, etc that Cygwin employs.

That is, the use of the special Unicode breakout character. It can
be used when a name collision is detected (yes, detection code required.
I don't know how costly that would be). eg.

Hello and HELLO, would end up with something like (posix=0 still
required on mount):

* Hello is created first. No Hello file preexists.
* attempt to create HELLO
* detect file exists as Hello, but filename not equal on case
* detect first case equal character is H.
* Use Unicode breakout on H in HELLO.
* Unfortunately, will need to recurse (expensive) and redo checks above
   (with breakout)

I haven't completely thought this through. And as I typed the above, it
sounds expensive. However, I'd love to hear opinion on this anyway.

Is the trade-off large enough to fall back on the "just use NTFS"
argument?

-- 
Thanks,
Shaddy

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple