Problems on case-sensitive file systems

Problems on case-sensitive file systems

[Thomas Wolff]

I'm facing a number of issues with case-sensitivity which I've collected:

There is a documented limitation on case-sensitivity using drive letter 
paths,
also mentioned in https://sourceware.org/ml/cygwin/2013-08/msg00090.html
(last item). I vaguely remember seeing a reason for this limitation in some
mail but can't find it again. I think it would be good to remove this
limitation because it breaks user expectations when working on
case-sensitive drives. Note I'm not asking about EXFAT (as in that thread)
but using Windows or mixed paths on NTFS or network drives, which should
be easy to transform/normalize for access.

According to documentation, the posix mount flag is enforced to be the same
for all mounts below /cygdrive; is there a strong reason? I think this
is not useful, because you may likely want data drives to be case-sensitive
but it's not good for the Windows system drive (because Windows is so silly
to have something like C:\WINDOWS\system32 in the path while the names are
C:\Windows\System32... as a workaround, I once set a symbolic link into C:\
- ln -s WINDOWS Windows. This worked nicely until I wanted to reboot and it
didn't find it's system folder anymore :( ).

To achieve the desired mount, I tried this:
D: /drives/d ntfs binary,nouser,posix=1,noumount
but somehow it does not seem to work for local drives while it works
nicely for network drives.

mv XY xy does not work if XY is a directory (no effect, no message)

If I switch Windows to case-sensitivity, there is no .EXE magic (only 
.exe magic).
So e.g. PING: command not found, while PING.EXE works.
Well, there are only a few .EXE files around, so this may be acceptable.

------
Thomas

--
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

Re: Problems on case-sensitive file systems

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

On 10/22/2014 01:01 AM, Thomas Wolff wrote:

> 
> mv XY xy does not work if XY is a directory (no effect, no message)

Might be something I can fix (I already have cygwin-local patches to
allow 'mv A.txt a.txt', so it is probably just incomplete if directories
aren't working).

> 
> If I switch Windows to case-sensitivity, there is no .EXE magic (only
> .exe magic).
> So e.g. PING: command not found, while PING.EXE works.

I know the .exe magic I added in coreutils tries to be case insensitive,
but I don't know if cygwin1.dll does the same; in the case of exec'ing a
program, that's the cygwin1.dll choosing whether to try all possible cases.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

Re: Problems on case-sensitive file systems

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

On Oct 22 07:52, Eric Blake wrote:
> On 10/22/2014 01:01 AM, Thomas Wolff wrote:
> 
> > 
> > mv XY xy does not work if XY is a directory (no effect, no message)
> 
> Might be something I can fix (I already have cygwin-local patches to
> allow 'mv A.txt a.txt', so it is probably just incomplete if directories
> aren't working).
> 
> > 
> > If I switch Windows to case-sensitivity, there is no .EXE magic (only
> > .exe magic).
> > So e.g. PING: command not found, while PING.EXE works.
> 
> I know the .exe magic I added in coreutils tries to be case insensitive,
> but I don't know if cygwin1.dll does the same; in the case of exec'ing a
> program, that's the cygwin1.dll choosing whether to try all possible cases.

Cygwin only recognizes lowercase .exe and .dll in casesensitive mode.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Problems on case-sensitive file systems

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]

On Oct 22 09:01, Thomas Wolff wrote:
> I'm facing a number of issues with case-sensitivity which I've collected:
> 
> There is a documented limitation on case-sensitivity using drive letter
> paths,
> also mentioned in https://sourceware.org/ml/cygwin/2013-08/msg00090.html
> (last item). I vaguely remember seeing a reason for this limitation in some
> mail but can't find it again. I think it would be good to remove this
> limitation because it breaks user expectations when working on
> case-sensitive drives.

The user expectation when using DOS paths is caseinsensitivity in the
first place.  But, as usual, there's no way to do this right, since
somebody will have another POV.  My stance is, don't use DOS paths when
using Cygwin.  At leats don't use DOS paths if you have any expectations
about special POSIX path handling on Cygwin.

> According to documentation, the posix mount flag is enforced to be the same
> for all mounts below /cygdrive; is there a strong reason?

Yes.  The flags are shared between all cygdrive paths.  If you need
something else, don;'t use the cygdrive path, but another, manually
added mount point.  Note that this:

 none /cygdrive cygdrive binary,posix=0,user 0 0
 D: /cygdrive/d ntfs binary,nouser,posix=1,noumount 0 0

does NOT work.  The manual paths must not overlap with the cygdrive
paths.  Use somehthing else instead:

 D: /drive_d ntfs binary,nouser,posix=1,noumount 0 0


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Problems on case-sensitive file systems

[Thomas Wolff]

Am 22.10.2014 16:00, schrieb Corinna Vinschen:
> On Oct 22 09:01, Thomas Wolff wrote:
>> I'm facing a number of issues with case-sensitivity which I've collected:
>>
>> There is a documented limitation on case-sensitivity using drive letter
>> paths,
>> also mentioned in https://sourceware.org/ml/cygwin/2013-08/msg00090.html
>> (last item). I vaguely remember seeing a reason for this limitation in some
>> mail but can't find it again. I think it would be good to remove this
>> limitation because it breaks user expectations when working on
>> case-sensitive drives.
> The user expectation when using DOS paths is caseinsensitivity in the
> first place.  But, as usual, there's no way to do this right, since
> somebody will have another POV.  My stance is, don't use DOS paths when
> using Cygwin.  At leats don't use DOS paths if you have any expectations
> about special POSIX path handling on Cygwin.
I use an application that uses Windows or mixed paths, I cannot 
influence it. So while I understand your POV, it would still be helpful 
to have path interpretation fully-featured. (If you point me to a place 
in winsup, I might even try to do something myself.)

>> According to documentation, the posix mount flag is enforced to be the same
>> for all mounts below /cygdrive; is there a strong reason?
> Yes.  The flags are shared between all cygdrive paths.  If you need
> something else, don;'t use the cygdrive path, but another, manually
> added mount point.  Note that this:
>
>   none /cygdrive cygdrive binary,posix=0,user 0 0
>   D: /cygdrive/d ntfs binary,nouser,posix=1,noumount 0 0
>
> does NOT work.  The manual paths must not overlap with the cygdrive
> paths.
I know and I did use a different path (maybe too similar to get 
recognized...). But it does not seem to work properly:
I have now this in /etc/fstab:
C: /mnt/c ntfs binary,nouser,posix=1,noumount 0 0
T: /mnt/t smbfs binary,user,posix=1,noumount,auto 0 0
which has no effect at all. Neither are these mounts set automatically 
when starting cygwin, nor can I refer to them by 'mount /mnt/t' ("mount: 
can't find /mnt/t in /etc/fstab or in /etc/fstab.d/$USER") or 'mount -a' 
(no effect).
The only thing that works is manual mounting:
mount -o posix=1 C: /mnt/c
mount -o posix=1,exec T: /mnt/t
But: while case-sensitivity now works in /mnt/c, it still does not in 
/mnt/t.
As a minor side-effect, the mount points in /cygdrive of these two 
drives now disappear from the list shown by 'mount' although they are 
still available as duplicate mounts.
------
Thomas

--
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

Re: Problems on case-sensitive file systems

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2520 bytes --]

On Oct 23 14:42, Thomas Wolff wrote:
> Am 22.10.2014 16:00, schrieb Corinna Vinschen:
> >On Oct 22 09:01, Thomas Wolff wrote:
> >>I'm facing a number of issues with case-sensitivity which I've collected:
> >>
> >>There is a documented limitation on case-sensitivity using drive letter
> >>paths,
> >>also mentioned in https://sourceware.org/ml/cygwin/2013-08/msg00090.html
> >>(last item). I vaguely remember seeing a reason for this limitation in some
> >>mail but can't find it again. I think it would be good to remove this
> >>limitation because it breaks user expectations when working on
> >>case-sensitive drives.
> >The user expectation when using DOS paths is caseinsensitivity in the
> >first place.  But, as usual, there's no way to do this right, since
> >somebody will have another POV.  My stance is, don't use DOS paths when
> >using Cygwin.  At leats don't use DOS paths if you have any expectations
> >about special POSIX path handling on Cygwin.
> I use an application that uses Windows or mixed paths, I cannot influence
> it. So while I understand your POV, it would still be helpful to have path
> interpretation fully-featured. (If you point me to a place in winsup, I
> might even try to do something myself.)

I'm not going to apply a patch to do that.  DOS paths get no special
treatment, they are always handled with DOS/Windows defaults.

> >>According to documentation, the posix mount flag is enforced to be the same
> >>for all mounts below /cygdrive; is there a strong reason?
> >Yes.  The flags are shared between all cygdrive paths.  If you need
> >something else, don;'t use the cygdrive path, but another, manually
> >added mount point.  Note that this:
> >
> >  none /cygdrive cygdrive binary,posix=0,user 0 0
> >  D: /cygdrive/d ntfs binary,nouser,posix=1,noumount 0 0
> >
> >does NOT work.  The manual paths must not overlap with the cygdrive
> >paths.
> I know and I did use a different path (maybe too similar to get
> recognized...). But it does not seem to work properly:
> I have now this in /etc/fstab:
> C: /mnt/c ntfs binary,nouser,posix=1,noumount 0 0
> T: /mnt/t smbfs binary,user,posix=1,noumount,auto 0 0

Drop the noumount and it will work.  noumount is an unknown mount flag
and, FWIW, not documented in
https://cygwin.com/cygwin-ug-net/using.html#mount-table


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Problems on case-sensitive file systems

[Thomas Wolff]

Am 23.10.2014 17:36, schrieb Corinna Vinschen:
> On Oct 23 14:42, Thomas Wolff wrote:
>> Am 22.10.2014 16:00, schrieb Corinna Vinschen:
>>> On Oct 22 09:01, Thomas Wolff wrote:
>>>> I'm facing a number of issues with case-sensitivity which I've collected:
>>>>
>>>> There is a documented limitation on case-sensitivity using drive letter
>>>> paths,
>>>> also mentioned in https://sourceware.org/ml/cygwin/2013-08/msg00090.html
>>>> (last item). I vaguely remember seeing a reason for this limitation in some
>>>> mail but can't find it again. I think it would be good to remove this
>>>> limitation because it breaks user expectations when working on
>>>> case-sensitive drives.
>>> The user expectation when using DOS paths is caseinsensitivity in the
>>> first place.  But, as usual, there's no way to do this right, since
>>> somebody will have another POV.  My stance is, don't use DOS paths when
>>> using Cygwin.  At leats don't use DOS paths if you have any expectations
>>> about special POSIX path handling on Cygwin.
>> I use an application that uses Windows or mixed paths, I cannot influence
>> it. So while I understand your POV, it would still be helpful to have path
>> interpretation fully-featured. (If you point me to a place in winsup, I
>> might even try to do something myself.)
> I'm not going to apply a patch to do that.  DOS paths get no special
> treatment, they are always handled with DOS/Windows defaults.
Any last chance to get a distinction here between X:\dos\paths and 
X:/mixed/paths?

>>>> According to documentation, the posix mount flag is enforced to be the same
>>>> for all mounts below /cygdrive; is there a strong reason?
>>> Yes.  The flags are shared between all cygdrive paths.  If you need
>>> something else, don;'t use the cygdrive path, but another, manually
>>> added mount point.  Note that this:
>>>
>>>   none /cygdrive cygdrive binary,posix=0,user 0 0
>>>   D: /cygdrive/d ntfs binary,nouser,posix=1,noumount 0 0
>>>
>>> does NOT work.  The manual paths must not overlap with the cygdrive
>>> paths.
>> I know and I did use a different path (maybe too similar to get
>> recognized...). But it does not seem to work properly:
>> I have now this in /etc/fstab:
>> C: /mnt/c ntfs binary,nouser,posix=1,noumount 0 0
>> T: /mnt/t smbfs binary,user,posix=1,noumount,auto 0 0
> Drop the noumount and it will work.  noumount is an unknown mount flag
> and, FWIW, not documented in
> https://cygwin.com/cygwin-ug-net/using.html#mount-table
Ah! Thanks.
That reminds me of that other problem I had previously observed but 
forgotten:
mount does not report option errors...
Also:
mount suggests this problem itself by reporting that very unknown option 
when running just 'mount'
And as a last, minor issue:
mount does not work on relative paths (like it does on Unix/Linux) but 
needs an absolute path:
mount /mnt/c # works
cd /mnt; mount c # does not work
------
Thomas

--
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

Re: Problems on case-sensitive file systems

[Andrey Repin]

Greetings, Thomas Wolff!

>>>>> I'm facing a number of issues with case-sensitivity which I've collected:
>>>>>
>>>>> There is a documented limitation on case-sensitivity using drive letter
>>>>> paths,
>>>>> also mentioned in https://sourceware.org/ml/cygwin/2013-08/msg00090.html
>>>>> (last item). I vaguely remember seeing a reason for this limitation in some
>>>>> mail but can't find it again. I think it would be good to remove this
>>>>> limitation because it breaks user expectations when working on
>>>>> case-sensitive drives.
>>>> The user expectation when using DOS paths is caseinsensitivity in the
>>>> first place.  But, as usual, there's no way to do this right, since
>>>> somebody will have another POV.  My stance is, don't use DOS paths when
>>>> using Cygwin.  At leats don't use DOS paths if you have any expectations
>>>> about special POSIX path handling on Cygwin.
>>> I use an application that uses Windows or mixed paths, I cannot influence
>>> it. So while I understand your POV, it would still be helpful to have path
>>> interpretation fully-featured. (If you point me to a place in winsup, I
>>> might even try to do something myself.)
>> I'm not going to apply a patch to do that.  DOS paths get no special
>> treatment, they are always handled with DOS/Windows defaults.
> Any last chance to get a distinction here between X:\dos\paths and 
> X:/mixed/paths?

No. It is the same path.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 24.10.2014, <1:49>

Sorry for my terrible english...


--
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

Re: Problems on case-sensitive file systems

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3352 bytes --]

On Oct 23 19:21, Thomas Wolff wrote:
> Am 23.10.2014 17:36, schrieb Corinna Vinschen:
> >On Oct 23 14:42, Thomas Wolff wrote:
> >>Am 22.10.2014 16:00, schrieb Corinna Vinschen:
> >>>On Oct 22 09:01, Thomas Wolff wrote:
> >>>>I'm facing a number of issues with case-sensitivity which I've collected:
> >>>>
> >>>>There is a documented limitation on case-sensitivity using drive letter
> >>>>paths,
> >>>>also mentioned in https://sourceware.org/ml/cygwin/2013-08/msg00090.html
> >>>>(last item). I vaguely remember seeing a reason for this limitation in some
> >>>>mail but can't find it again. I think it would be good to remove this
> >>>>limitation because it breaks user expectations when working on
> >>>>case-sensitive drives.
> >>>The user expectation when using DOS paths is caseinsensitivity in the
> >>>first place.  But, as usual, there's no way to do this right, since
> >>>somebody will have another POV.  My stance is, don't use DOS paths when
> >>>using Cygwin.  At leats don't use DOS paths if you have any expectations
> >>>about special POSIX path handling on Cygwin.
> >>I use an application that uses Windows or mixed paths, I cannot influence
> >>it. So while I understand your POV, it would still be helpful to have path
> >>interpretation fully-featured. (If you point me to a place in winsup, I
> >>might even try to do something myself.)
> >I'm not going to apply a patch to do that.  DOS paths get no special
> >treatment, they are always handled with DOS/Windows defaults.
> Any last chance to get a distinction here between X:\dos\paths and
> X:/mixed/paths?

As Andrey already wrote, it's pretty much the same thing.  As soon as 
you're using DOS paths (and drive letter paths with slashes are still
DOS paths), the assumption is that the application expects DOS semantics.

> >>I have now this in /etc/fstab:
> >>C: /mnt/c ntfs binary,nouser,posix=1,noumount 0 0
> >>T: /mnt/t smbfs binary,user,posix=1,noumount,auto 0 0
> >Drop the noumount and it will work.  noumount is an unknown mount flag
> >and, FWIW, not documented in
> >https://cygwin.com/cygwin-ug-net/using.html#mount-table
> Ah! Thanks.
> That reminds me of that other problem I had previously observed but
> forgotten:
> mount does not report option errors...

Right.  Mount doesn't know the valid options by itself.  It gets a list
by calling into the Cygwin DLL.  The fact that mount doesn't check them
and report unknown options is a bit awkward.  Patches welcome.

> Also:
> mount suggests this problem itself by reporting that very unknown option
> when running just 'mount'

Uh, yes.  This is the option historically printed for cygdrive
mount points.  It's not a valid option for fstab, though.

> And as a last, minor issue:
> mount does not work on relative paths (like it does on Unix/Linux) but needs
> an absolute path:
> mount /mnt/c # works
> cd /mnt; mount c # does not work

This is historical, too.  There never has gone much work into mount
since it was most of the time "good enough".  If you want to get
relative pathname support for the POSIX side of mount points, feel
free to hack away.  It's a neat feature.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]