[PATCH] Allow manipulating files with long names on Windows

[Aaron Cohen]

On Tue, Jan 25, 2011 at 8:00 AM, timeless <timeless at gmail.com> wrote:
> :(

It's not that big a deal if it has to stay a 3rd party extension. I'm
committed to maintaining it in any event, because I quite literally
can't accomplish any work at my dayjob if it breaks.

> can explorer follow a junction/symlink through a long filename/path?
>
> if so, would it be useful for an lfn extension to create automatic
> ignored links on ntfs to help explorer users?
>
> the goal of lfn seems to me to be to enable lfn users to deal with
> repositories created by non windows users which are currently not
> usable by windows users. if adding extra links makes them work, then
> that's what we should do.

Well, it's also perfectly possible to create these directories in
Windows (in IntellIJ or Eclipse for instance) and then have hg unable
to deal with them.

I'm harping on Java because Java projects are in my experience more
likely to have deep paths, and as a result, their tools support them.
Between the verbose recommended maven directory layout:
project/project-module/src/main/java, and the recommended package name
format com.hostname.project.package (each of which implies a directory
component) and Java file identifiers typically being quite verbose
such as XmlRpcComponentFactoryFactory.java, it's ridiculously easy to
exceed MAX_PATH.

>
> otoh, if the right thing to do is to go the other way, i.e. have lfn
> provide and track short names but create symlinks for the long names,
> then maybe we should do that instead :).

(snip)

> -- Yes, i'm on a windows computer now (got home from vacation), but
> I'm over a week behind on things and don't have time to test/prototype
> stuff. So I'm just going to toss out ideas and hope people are willing
> to try to run with them.
>
> fwiw, if you're going to do shortening, i'd go w/ the old ntfs
> algorithm of ~[4randomish-chars] and do it as
> [239chars]~[4randomish-chars].[last-extension] where 239chars gets
> shorter if last-extension is more than 3 characters long. Don't have a
> distinction between long files and long directories. I didn't spell
> out that in my example because that's too painful to type :).
>

I'm not sure I understand how using symlinks would help, users would
still end up with files on their system that traditional tools can't
handle, they'd just be symlinks rather than files.

Rather than creating "short files" it might be an idea to make more
use of the "alternateFileName" that Windows has for long files (which
is the old 8.3 truncated filename and does look like 6chars~1), but
I'm not sure there's any reason to since my extension seems to work
well enough as it is.

Do you mean adding a command such as "hg lfn --truncate" which would
search for long paths in the repo and replace them with short
versions? I could certainly implement that if requested, but I'm not
sure it's necessary. "hg lfn --clean" eliminates the single biggest
gotcha which is "I've checked out this repository and now I can't
delete it."