QUERY behaviour on a Case-Insensitive/Case-Preserving Filesystem

[rgchris]

I get the following behaviour on OS X:

>> write %foo.txt "Foo" 
== #[port! [...] [...]]

>> query %FOO.TXT
== make object! [
    name: %FOO.TXT
    size: 3
    date: 13-Feb-2020/14:11:30-5:00
    type: 'file
]

I propose in these cases that the NAME field is adjusted to reflect the case as stored in the filesystem such that it can be handled at a script level.

[hostilefork]

This is a nice idea, but sadly neither Windows nor Mac are set up particularly well to do this.

There's a lot of nuance in filesystems when it comes to things like drive letters, "UNC paths", symbolic links, etc. And no one in the case-insensitive filename world seemed to think this canonization was important enough to provide a failsafe mechanism for doing it.

On Windows, if one is willing to link to OLE libraries it seems there might be a turnkey method by invoking Scripting.FileSystemObject. But that brings in dependencies to the Windows executable we don't currently have (OLE32.DLL, OLEAUT.DLL, UUID.LIB). Other approaches are just sort of hacked together as you might imagine--by enumerating the file system itself and looking for matches... it just can be made a little faster if you use internal APIs.

Mac might have a way to do it, but with APIs that are in Objective-C and not C. But as the comments suggest there, it isn't necessarily cut and dry that any of this is right.

I think the right thing to do is probably to canonize this on-demand in usermode Rebol. With a fine-grained directory listing method, you could basically get the equivalent of "ls filename" and get back only matching entries...it should be fast enough. This would work cross platform. It might not be super fast, but if we modify QUERY to only ask for what it needs, then you wouldn't be paying for it if you just wanted to know the filesize/etc.