[Octave-bug-tracker] [bug #49118] GUI editor cannot run file in folder name with umlaut

[Markus Mützel]

Follow-up Comment #69, bug #49118 (project octave):

Add function that returns an ASCII-only file name corresponding to the input
file name here:
http://hg.savannah.gnu.org/hgweb/octave/rev/7dad5fa7e88e

TL;DR:
Any better ideas how to handle the situation on Windows?
Does it make sense to inline this function for Linux? How should that be
done?

Some further explanations for the motivation:
At quite a few places in the code we are passing file names as char arrays to
external library functions (or gnulib and standard functions fwiw).
When these functions try to locate the corresponding file on the disc, they
would need to use the wide character API on Windows to correctly open files
with non-ASCII characters.
But they have no way of knowing which encoding we are using for the passed
string. So they have no way of reliably converting to a wchar_t array. (I.e.
there is no possible fix for these functions with current C/C++.)

To solve the dilemma, the function "get_ASCII_filename" first checks whether
there are any non-ASCII characters in the passed file name. If there are not,
it returns the original name.
Otherwise, it tries to obtain the short file name (8.3 naming scheme) which
only consist of ASCII characters and are save to pass. However, short file
names can be disabled for performance reasons on the file system level with
NTFS. So there is no guarantee that these exist.
If short file names are not stored, a hard link to the file is created. For
this the path to the file is split at the deepest possible level that doesn't
contain non-ASCII characters. At that level a hidden folder is created that
holds the hard links. That means we need to have write access on that
location. A path to that hard link is returned.

If the file system is FAT32, there are no hard links. But FAT32 always stores
short file names. So we are save.

ExFAT that is occasionally used on USB sticks and SD cards stores neither
short file names nor does it support hard links. So for exFAT with this
function, there is (currently) no way to generate a file name that is stripped
from non-ASCII characters but still is valid.

For Linux, this function essentially does nothing. It might be good idea if it
could be inlined (and eventually optimized out by the compiler). But the
Windows branch is much too large to be included in the header (I guess).

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?49118>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/