> -----Original Message-----
> From: Branko Čibej [mailto:brane_at_wandisco.com]
> Sent: donderdag 29 augustus 2013 11:01
> To: dev_at_subversion.apache.org
> Subject: Re: AW: Long Pathes on Windows and SQLite
>
> On 29.08.2013 08:10, Markus Schaber wrote:
> > Hi, Bert,
> >
> > Von: Bert Huijben [mailto:bert_at_qqmail.nl]
> >> From: Markus Schaber [mailto:m.schaber_at_codesys.com]
> >>> Von: Branko Čibej [mailto:brane_at_wandisco.com]
> >>>> On 22.08.2013 14:26, Markus Schaber wrote:
> >>>>> Some days ago, I stumbled across a problem, and could analyze it a
> >>>>> little bit those days.
> >>>>>
> >>>>> Windows has a general limit on the path length of 260 characters
> >>>>> on some APIs, while others allow a length of about 32k characters
> >>>>> (with some restrictions).
> >>>>>
> >>>>> Most (if not all) of the SVN codebase seems to work fine with
> >>>>> those long pathes.
> >>>> Yes, APR takes care to use the Unicode APIs and use \\?.
> >>>>
> >>>>> However, it seems that SQLite is not (yet) long path clean:
> >>> [....]
> >>> I did also contact the SQLite developers about this issue, and in
> >>> http://www.mail-archive.com/sqlite-users@sqlite.org/msg78853.html,
> >>> Richard Hipp saids:
> >>>
> >>> | SQLite version 3.8.0 allows for longer windows pathnames up to
> >>> | 3*MAX_PATH bytes, which is 3x more space that was allowed before.
> >>> | This
> >>> is
> >>> | still not 32K but might be sufficient for your needs. The limit can
> >>> | be extended at compile-time.
> >>>
> >>> This could help us to solve the problem.
> >> Looking at the patch this is not going to solve your issue.
> >> [http://www.sqlite.org/src/info/bb06e15790]
> >>
> >> This makes it possible to use paths that need more bytes to encode a
> path,
> >> but it doesn't lift the MAX_PATH characters in Unicode limitation in the
> way
> >> APR does via absolute paths and using the \\?\ override to certain API
> >> functions.
> > There's good news on the SQLite side:
> >
> > http://www.mail-archive.com/sqlite-users@sqlite.org/msg78853.html
> says:
> >
> > | The latest check-in on trunk adds a new windows VFS module called
> > | "win32-longpath" which accepts the full-length 32KB pathnames. Add the
> > | string "win32-longpath" as the 4th argument to sqlite3_open_v2() (on
> > | windows only, of course) and everything should just work after that.
> >
> > The source change is at http://www.sqlite.org/cgi/src/info/12d0a8859d
> >
> > It seems this new VFS supports long path names if they start with the \\?\
> prefix.
> >
> > So as soon as the next SQLite version is released, we can include support
> for it into SVN, maybe with a compile-time check on what SQLite version is
> available.
>
> It will have to be a runtime check, but that's OK. On the other hand,
> we'd have to hoist APR's code for creating those prefixed paths in the
> first place. It's currently private in APR, and I'm not too happy with
> the idea of duplicating it ...
I'm starting to think that we might want to raise our requirements to 3.8.0 for Subversion 1.9.0 anyway for other reasons (Partial indexes will improve performance for quite some cases), so maybe we should go to 3.8.1.
Given that the Windows Explorer and many other programs don't handle these long paths anyway, I'm not really interested in this specific fix. A nicer fix would be to finally start storing external information in their parent working copy.
(Which is on my backlog combined with 'svn stash' preparations)
Bert
Received on 2013-08-29 11:09:00 CEST