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