This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problems on case-sensitive file systems

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
> >>>>(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
> >
> 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 Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgp_3uAUFLO5Y.pgp
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]