Skip Menu |

This queue is for tickets about the PathTools CPAN distribution.

Report information
The Basics
Id: 82336
Status: open
Priority: 0/
Queue: PathTools

People
Owner: Nobody in particular
Requestors: victor [...] vsespb.ru
Cc: ether [...] cpan.org
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)



Subject: File::Spec::case_tolerant on Mac OS X
As I understood you have File::Spec::Unix for Unix and Mac OS X and File::Spec::Mac for Mac OS Classic So File::Spec::case_tolerant returns 0 for Mac OS X ? But seems it should return 1 for some Mac OS X filesystems.
Yes, I agree. Furthermore, it's not really a function of the OS, but of the filesystem. I don't have a great solution for it but proposals would be good.
On Mon Dec 31 03:12:01 2012, KWILLIAMS wrote: Show quoted text
> Yes, I agree. Furthermore, it's not really a function of the OS, but > of the filesystem. I don't have > a great solution for it but proposals would be good.
Well, I am not Mac developer.. But seems need to return "1" for modern Mac OS X, as case insensetive filesystem is a default for it (furthermore AFAIK some Mac apps are broken on case sensetive filesystems) But I am absolutely not sure if this will or will not break compatibility with existing perl code. For per-filesystem you can introduce new API and check it this way: http://apple.stackexchange.com/questions/71357/how-to-check-if-my-hd-is-case-sensitive-or-not btw there is already a ticket related to MacOSX https://rt.cpan.org/Ticket/Display.html?id=1790 but looks fix is wrong (as MacOSX is not MacOS - it does not use ':' as directory separator)
Subject: File::Spec::case_tolerant is flawed
On 2013-01-02 01:45:21, vsespb wrote: Show quoted text
> On Mon Dec 31 03:12:01 2012, KWILLIAMS wrote:
> > Yes, I agree. Furthermore, it's not really a function of the OS, but > > of the filesystem. I don't have > > a great solution for it but proposals would be good.
Fundementally, it is an error to assume the value of this variable simply by looking at the architecture. Defaults can be wrong, and the value can differ depending on the path in question, as multiple filesystems can be in use. I don't think this function can serve any useful purpose, as the caller is bound to misuse the information. The only sane thing for a caller to do when considering two foldcase-identical paths is to stat() the files in question and see if they refer to the same physical resource. I think the correct thing to do is to deprecate this function entirely and insert a big warning that its return value cannot and should not be trusted.