issue with large file path on windows
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=sharin... 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
This is great news! I had tons of problems last year with that and I did not know what to do about this. Doru On Sun, Aug 23, 2015 at 1:44 PM, Nicolai Hess <nicolaihess@web.de> wrote:
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=sharin...
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
-- www.tudorgirba.com "Every thing has its own flow"
Le 23/08/2015 14:28, Tudor Girba a écrit :
This is great news!
I had tons of problems last year with that and I did not know what to do about this.
A possible solution would have been to rewrite a bit the filetree support so that it could load packages directly from the zip archive downloaded from github, instead of unpackaging it to disk. But... pushing for the windows vm so that it would use the right API is a lot better :) Thanks Nicolai, Thierry
Doru
On Sun, Aug 23, 2015 at 1:44 PM, Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote:
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=sharin...
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
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
And If you want to review the changes: https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-lon... 2015-08-23 13:44 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:
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=sharin...
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
On 23 Aug 2015, at 6:09 , Nicolai Hess <nicolaihess@web.de> wrote:
And If you want to review the changes:
https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-lon... <https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-lon...>
2015-08-23 13:44 GMT+02:00 Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>>: 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=sharin... <https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=sharin...>
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 "\\?\ <smb://?/>" 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
2015-08-24 13:34 GMT+02:00 Henrik Johansen <henrik.s.johansen@veloxit.no>:
On 23 Aug 2015, at 6:09 , Nicolai Hess <nicolaihess@web.de> wrote:
And If you want to review the changes:
https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-lon...
2015-08-23 13:44 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:
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=sharin...
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
participants (4)
-
Henrik Johansen -
Nicolai Hess -
Thierry Goubier -
Tudor Girba