This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: utf-8 and cygwin


Gregg Tavares wrote:

> I see that someone says they are working on it for a future release but a search also brought up this patch
> 
> http://www.okisoft.co.jp/esc/utf8-cygwin/
> 
> which already does that. I thought maybe whoever is working on future utf-8 support might want to look at that.

This patch has already been studied and rejected for inclusion in
Cygwin.  The reason is that it just adds some wrappers around certain
functions, but it does not cause Cygwin to actually use Unicode
throughout.

> after trying that out both unison and rsync started working with out a recompile for short filenames which brings up the second issue
> 
> #2) The filename size limit in cygwin is too short.

This is a Windows limitation when using the ANSI versions of the Win32
api.  Windows limits paths to 260 (including the leading drive
letter+colon+backslash and null) and there's nothing Cygwin can do about
this.  Just changing some defines would not make longer paths work.

If you switch to the wide character versions of the Win32 API you can
handle paths as long as 32000 Unicode characters.  And that is why
Corinna has been slowly refactoring the whole code base so that all
paths are stored and manipulated internally as Unicode strings, which
leads to calling the W versions of the win32api (or the Native version,
since we've decided to no longer support Win9x) without any wrappers.

What's in CVS now is a work in progress.  It is not finished, and so you
can't expect it to do anything differently yet.  It's a lot of work to
refactor every bit of code that touches a file/pathname to handle
unicode.

Brian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]