AFAIK, this affects NTFS too. I believe the semantics are "store as case-sensitive, retrieve as case insensitive".
And, FWIW, this was right PITA for the Python binding effort; in the end, in my "unofficial" version I went with only shipping the new CamelCase files where possible. I'm not exactly sure what solution Stephen went with for the "official" CMake-driven version. On 5 May 2016 at 08:48, René J.V. <[email protected]> wrote: > On Wednesday May 04 2016 22:51:04 Marko Käning wrote: > > Hi Marko, > >>a directory KF5/Foo/foo and the corresponding "CamelCase" headers in >>KF5/Foo/Foo . >> >>oh, no! Not again. > > Oh yes, "all of this has happened before and all of this will happen again" > ... > >>I am case-insensitive here as well. This should not happen on such file >>systems!!! > > Well, it *will* happen on such filesystems. The only alternative is that the > filesystem would raise an error when trying to create a new dir entry with a > supposedly different name that maps to the name of an already existent entry. > I think that's what higher-level applications like the Finder or the MSWin > Explorer do, but it would probably break too many expectations for > lower-level, Unix/Posix calls. > The only solution is to avoid naming schemes where this kind of clash can > occur. That is, to follow guidelines Michael Pyne posted the other day: > > 1. Do not accidentally lose information about differences in case (e.g. if > user does "Save As" as "xSa" then the resulting file name sent to FS should be > "xSa") > > 2. Do not rely on file names that differ only in case (e.g. don't install a > fileA.foo and FileA.foo and expect to be able to open a precise one of those > two later) > >>> The sheer amount of KF5 frameworks concerned means (IMVHO) that we should >>> really strive for an upstream solution rather than having to maintain our >>> own set of patches … >> >>I haven’t tested all this lately, but I remember that I ran into trouble with >>this because of phonon in Januar 15. > > Ah, that's not a KF5 framework, but I'll have another look. First impression > though is that no clashes can occur, at least in its current MacPorts > installation layout. > > R. > _______________________________________________ > Kde-buildsystem mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/kde-buildsystem _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
