Smalltalk › Pharo › Pharo Smalltalk Developers

What is blocking Pharo from supporting long paths on Windows?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

Peter Uhnak

What is blocking Pharo from supporting long paths on Windows?

So I wanted to update Iceberg in one of my PharoLauncher managed issues.

Of course the load failed on some missing file... upon further exploration:

updating Iceberg updates Metacello, and metacello contains content like

Metacello-metacello-1af26bf/repository/Metacello-ToolBox.package/MetacelloToolBox.class/instance/modifySection.sectionIndex.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups.versionSpecsDo..st (271 characters - longest file path)

Metacello-metacello-1af26bf/repository/Metacello-GemStone-TestsMCB.package/MetacelloScriptingRegistryDisableUndefinedSymbolsTestCase.extension/instance/ (152 characters - longest directory path)

To that you need to add the path to the image (44 chars for me), name of the image (35 chars on avg for me), and the local location (github-cache\metacello\metacello\Pharo6.1) (41 chars).

tl;dr: 120 chararacters out of Windows 260 is taken by fixed cost, and I need to fit 152+ characters (that's just directory, it includes files of course) into 140 chars.

I have longPathsEnabled in Windows (10) and some applications indeed can go beyond the limit --- e.g. I can clone (with git) metacello to the same directory (and go over the limit), but Pharo will fail if I try to navigate to it. So clearly my system supports it, but not Pharo.

In conclusion:

Anyone familiar with WinAPI knows what needs to be done for Pharo to support unlimited/long paths?

Thanks,

Peter

alistairgrant

Re: What is blocking Pharo from supporting long paths on Windows?

Hi Peter,

On Tue, Oct 17, 2017 at 09:16:49PM +0200, Peter Uhn??k wrote:

> So I wanted to update Iceberg in one of my PharoLauncher managed issues.
> Of course the load failed on some missing file... upon further exploration:
>
> updating Iceberg updates Metacello, and metacello contains content like
>
> Metacello-metacello-1af26bf/repository/Metacello-ToolBox.package/
> MetacelloToolBox.class/instance/
> modifySection.sectionIndex.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups.versionSpecsDo..st
> (271 characters - longest file path)
>
> or
>
> Metacello-metacello-1af26bf/repository/Metacello-GemStone-TestsMCB.package/
> MetacelloScriptingRegistryDisableUndefinedSymbolsTestCase.extension/instance/
> (152 characters - longest directory path)
>
> To that you need to add the path to the image (44 chars for me), name of the
> image (35 chars on avg for me), and the local location (github-cache\metacello\
> metacello\Pharo6.1) (41 chars).
>
> tl;dr: 120 chararacters out of Windows 260 is taken by fixed cost, and I need
> to fit 152+ characters (that's just directory, it includes files of course)
> into 140 chars.
>
> I have longPathsEnabled in Windows (10) and some applications indeed can go
> beyond the limit --- e.g. I can clone (with git) metacello to the same
> directory (and go over the limit), but Pharo will fail if I try to navigate to
> it. So clearly my system supports it, but not Pharo.
>
> In conclusion:
>
> Anyone familiar with WinAPI knows what needs to be done for Pharo to support
> unlimited/long paths?
>
> Thanks,
> Peter

I'm not familiar with the Win API, but probably what you are looking for
is covered by this comment in sqWin32File.h:

Handles paths longer than 260 characters (including NULL) by prepending
"\\?\" to encode UNC paths as suggested in
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#maxpath

"The maximum path of 32,767 characters is approximate,
because the "\\?\" prefix may be expanded to a longer
string by the system at run time, and this expansion
applies to the total length."

FilePlugin already does this, so normal directory traversal, i.e. using
FileReference, within Pharo should be working correctly.

Cheers,
Alistair