[GRASS-dev] Re: [GRASS-user] Cannot use grass on vfat partition

[Glynn Clements]

Maris Nartiss wrote:

> I changed that ugly PERMANENT check in gis_set.tcl file, but IMHO it
> will not help in this case, as tcl (gis_set.tcl), shell (init.sh) and
> C modules (g.region and firends) still will work in case-sensitive way
> in case-sensitive systems (Linux and other Unix-like systems). IMHO
> this should be just added to list of known issues.
> Correct me, if I'm wrong.

If a program accesses (open(), stat(), access(), etc) a file on a
case-insensitive filesystem, the access will work regardless of case.

If you create a file named "WIND" on a FAT (or SMB) filesystem, and
the filename gets converted to "wind", calling e.g. open("WIND",...) 
will still open the file. The filesystem driver knows whether the
filesystem is case-sensitive or not.

The problem comes when the code tries to do the lookup itself, by
enumerating the directory (opendir(), readdir(), closedir()) then
matching the filename with e.g. strcmp(). The program cannot easily
tell whether the directory resides on a case-sensitive filesystem. You
can't just use "#ifdef __MINGW32__", as Linux can access FAT
partitions and SMB shares, while Windows systems can access Samba
servers which export case-sensitive filesystems (also, NTFS allows
case-sensitive directories, but they aren't often used, as a lot of
Windows software doesn't handle this correctly).

Apart from the issue of case-sensitivity, there's also the fact that
enumeration requires more privilege than lookup[1], and it may also
have implications regarding Unicode normalisation[2].

[1] I doubt that this will be an issue for GRASS databases, but on
shared servers it's quite common for "system" directories to be mode
711 (drwx--x--x), so processes owned by normal users can access known
system files but cannot enumerate the directories.

[2] On OSX, accented characters (in filenames) are stored as a
combination of a non-accented character and a composing accent
character. The higher-level library functions (I don't know about
fopen() etc) automatically normalise filenames, so the string returned
from readdir() won't necessarily match the string passed to the
function which created the file.

-- 
Glynn Clements <glynn at gclements.plus.com>