Re: Bug #33255 (Windows cannot open files with non-ascii names)

[John Darrington]

On Thu, Oct 08, 2015 at 09:29:35PM -0700, Ben Pfaff wrote:
     On Thu, Oct 08, 2015 at 06:47:05PM +0200, John Darrington wrote:
     > In addition to the changes I've submitted for review, I think the 
resolution to this 
     > problem involves work in src/data/make-file.c
     > 
     > The issue is, this module contains a lot of calls to posix file 
functions, such as 
     > open, rename, unlink etc.
     > 
     > These work in w32 so long as there are no non-ascii characters in the 
filenames.
     > To get other characters to work, we have to do two things:
     > 
     > 1. Convert the filenames to UTF-16LE
     > AND
     > 2. replace the function calls by their WideChar equivalents.
     > 
     > Step 2  however has caveats:
     > 
     > open --> _wopen is no problem.
     > unlink --> _wunlink is no problem.
     > rename --> _wrename will not work, because windows rename refuses to 
overwrite an existing file.  We will 
     >  have to use the native Windows function MoveFileW
     > 
     > Not sure about stat.
     > 
     > 
     > It may end up being easier to have a platform specific implementation of 
make-file.c
     > 
     > What do you think?
     
     Can this be fixed in Gnulib somehow?

It probably can be.  The question one has to ask is does it make sense to do so:

The awkward issue is the _wrename function.   The POSIX rename silently 
overwrites
the target.  The Windows rename (and presumably the corresponding _wrename) 
however 
fails with an error if the target exists.

Now some years ago, we (you actually!) contributed a replacement rename to 
Gnulib 
such that it behaves per POSIX on Windows.  I think it is perfectly possible to 
write a replacement _wrename for w32 which behaves in a more POSIX like way,
however then it will not behave how Microsoft's documentation says.

Perhaps it might make sense to have a "widechar" version of rename in Gnulib, 
but
call it something other than _wrename.


     
     A system-specific implementation makes sense except that we lack proper
     resources to test it.

That is true.  The pros and cons of both solutions need to be considered 
carefully.

J'

-- 
Avoid eavesdropping.  Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

signature.asc
Description: Digital signature