Re: [Pharo-users] issue with large file path on windows

[Nicolai Hess]

2015-08-24 13:34 GMT+02:00 Henrik Johansen :

>
> On 23 Aug 2015, at 6:09 , Nicolai Hess  wrote:
>
> And If you want to review the changes:
>
>
> https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-long-filename
>
>
> 2015-08-23 13:44 GMT+02:00 Nicolai Hess :
>
>> For those who had problems with pharo on windows and github based
>> repositories,
>> I built a windows vm with support for long paths:
>>
>>
>> https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=sharing
>>
>>
>> For browsing directories with large paths (FileList or Inspect),
>> you may need one additional change in the image (But I am not really sure
>> about that) :
>>
>> DiskStore>>initialize
>> super initialize.
>> maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 ].
>>
>>
>> please test and give feedback.
>>
>> This wasn't as easy as I thought, and I had to make some more changes
>> for the file permissions (the stat-functions don't work for files with
>> long paths).
>> Please test other file/folder operations.
>>
>>
>> nicolai
>>
>>
>>
>>
>
>
Thank you Henrik, for looking at this



> + #define CONVERT_MULTIBYTE_TO_WIDECHAR_PATH(buffer, size,
> fileNameString, fileNameLength) { \+ buffer = (WCHAR*)alloca((size+4+1)*
> sizeof(WCHAR));\+ buffer[0] = L'\\';buffer[1] = L'\\'; buffer[2] = L'?';
> buffer[3] = L'\\';\+ MultiByteToWideChar(CP_UTF8, 0, fileNameString,
> fileNameLength, buffer + 4, size);\+ buffer[size + 4] = 0;\+ size += 4;}
>
>
> - Is an alloca version really worth it for the potential problems?
>

It is what Marcel used for the long path support in the squeak vm (I would
have copy and paste the whole change, but I couldn't find the appropriate
change for directory functions).


> - Also, LONG_PATH_PREFIX_SIZE is defined above in the header, should
> probably use this instead of 4 in the last two lines?
>

Yes


> - The comment on lines 111/164/265/381, while not modified, are somewhat
> incorrect, null-terminated C-string indicates UTF8, which we are converting
> from, not into.
>

Right, I ll chang that

>
> I'm curious what the "\\?\" prefix does to hasCaseSensitiveDuplicate
> (adding a new ? segment to the path), but I cba to understand that code,
> and considering
> int caseSensitiveFileMode = 0;
> if(!caseSensitiveFileMode) return 0;
>
> I guess it doesn't really matter.
>

Yes, I tried to make this change in a way that does not break the case
sensitive duplicate check, but even without my change,
enabling the caseSenstiveFileMode makes the windows vm unusable. So, at
least, it is no worse.



>
> Otherwise, looks good to me!
>
> Cheers,
> Henry
>

Re: [Pharo-users] issue with large file path on windows

[Henrik Johansen]

> On 23 Aug 2015, at 6:09 , Nicolai Hess  wrote:
> 
> And If you want to review the changes:
> 
> https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-long-filename
>  
> 
> 
> 
> 2015-08-23 13:44 GMT+02:00 Nicolai Hess  >:
> For those who had problems with pharo on windows and github based 
> repositories,
> I built a windows vm with support for long paths:
> 
> https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=sharing 
> 
> 
> 
> For browsing directories with large paths (FileList or Inspect),
> you may need one additional change in the image (But I am not really sure 
> about that) :
> 
> DiskStore>>initialize
> super initialize.
> maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 ].
> 
> 
> please test and give feedback.
> 
> This wasn't as easy as I thought, and I had to make some more changes
> for the file permissions (the stat-functions don't work for files with long 
> paths).
> Please test other file/folder operations.
> 
> 
> nicolai
> 
> 
> 
> 

+  #define CONVERT_MULTIBYTE_TO_WIDECHAR_PATH(buffer, size, fileNameString, 
fileNameLength)  {  \
+buffer = (WCHAR*)alloca((size+4+1)*sizeof(WCHAR));\
+buffer[0] = L'\\';buffer[1] = L'\\'; buffer[2] = L'?'; buffer[3] = L'\\';\
+MultiByteToWideChar(CP_UTF8, 0, fileNameString, fileNameLength, buffer + 
4, size);\
+buffer[size + 4] = 0;\
+size += 4;}


- Is an alloca version really worth it for the potential problems?
- Also, LONG_PATH_PREFIX_SIZE is defined above in the header, should probably 
use this instead of 4 in the last two lines?
- The comment on lines 111/164/265/381, while not modified, are somewhat 
incorrect, null-terminated C-string indicates UTF8, which we are converting 
from, not into.

I'm curious what the "\\?\ " prefix does to hasCaseSensitiveDuplicate 
(adding a new ? segment to the path), but I cba to understand that code, and 
considering
int caseSensitiveFileMode = 0;
if(!caseSensitiveFileMode) return 0;

I guess it doesn't really matter.

Otherwise, looks good to me!

Cheers,
Henry

Re: [Pharo-users] issue with large file path on windows

[Nicolai Hess]

And If you want to review the changes:

https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-long-filename


2015-08-23 13:44 GMT+02:00 Nicolai Hess :

> For those who had problems with pharo on windows and github based
> repositories,
> I built a windows vm with support for long paths:
>
>
> https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=sharing
>
>
> For browsing directories with large paths (FileList or Inspect),
> you may need one additional change in the image (But I am not really sure
> about that) :
>
> DiskStore>>initialize
> super initialize.
> maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 ].
>
>
> please test and give feedback.
>
> This wasn't as easy as I thought, and I had to make some more changes
> for the file permissions (the stat-functions don't work for files with
> long paths).
> Please test other file/folder operations.
>
>
> nicolai
>
>
>
>

[Pharo-users] issue with large file path on windows

[Nicolai Hess]

For those who had problems with pharo on windows and github based
repositories,
I built a windows vm with support for long paths:

https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=sharing


For browsing directories with large paths (FileList or Inspect),
you may need one additional change in the image (But I am not really sure
about that) :

DiskStore>>initialize
super initialize.
maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 ].


please test and give feedback.

This wasn't as easy as I thought, and I had to make some more changes
for the file permissions (the stat-functions don't work for files with long
paths).
Please test other file/folder operations.


nicolai