[PATCH 0 of 1 v4] win32lfn: allow manipulating files with long names on Windows

[Aaron Cohen]

On Mon, Jan 24, 2011 at 6:34 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Mon, 2011-01-24 at 01:11 -0500, Aaron Cohen wrote:
> So here's where I am on this. Possible options are:
>
> a) add it to hgext/, with whatever level of support that implies
> b) add it to contrib/, with whatever lesser level of support that
> implies, possibly moving to hgext/ in the future
> c) add it to Extensions on the wiki, possibly moving to hgext/ in the
> future

I'll go ahead and make a wiki page, it can always move from one place
to another.

> It's obviously really frustrating for us that Windows is so broken in
> regards to just about everything related to filenames. So it's really
> attractive to bypass a big chunk of that with UNC-style names. On the
> other hand, the support for such things is desperately thin, starting
> with Explorer, and it's hard to see how filenames that aren't even
> browsable/deletable with Explorer are going to be viable.

Well, hg wouldn't be the only tool that can produce these files. And
maybe if more tools produce them, Microsoft will get working on a
solution...

I agree that it's an annoying problem though.

> Currently, we don't get much complaint about long file names, so I don't
> think there's enough demand for us to justify the potential support cost
> of having this in-tree. So my inclination is for this to live
> out-of-tree until we find ourselves recommending it to people on a
> regular basis.

Fair enough.

> By the way, you should probably give some thought to how this relates to
> the win-utf8 extension or whatever it's called, which is almost but not
> quite orthogonal.

I've been giving a lot of thought to this over the past week. That
extension converts everything to unicode and uses the unicode family
of filesystem functions, but you're right, that extension, mine and
win32mcbs are all fundamentally just inserting a normalization step
before calling the API functions.

I found a post you made a while ago saying that the fundamentals are
there to handle the UTF normalization problems in a similar way to the
way Windows' case insensitivity is being done. Do you happen to have
time to describe how that would look?

--Aaron