[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug #33255 (Windows cannot open files with non-ascii names)
From: |
Ben Pfaff |
Subject: |
Re: Bug #33255 (Windows cannot open files with non-ascii names) |
Date: |
Fri, 9 Oct 2015 08:02:43 -0700 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Fri, Oct 09, 2015 at 07:29:12AM +0200, John Darrington wrote:
> 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.
I guess I was assuming that we'd provide a replacement rename(), or I
guess enhance the existing rename() replacement, so that it accepted
UTF-8 file names. It could be implemented in terms of MoveFileW or
whatever is appropriate.