2015-08-24 13:34 GMT+02:00 Henrik Johansen <henrik.s.johan...@veloxit.no>:
> > On 23 Aug 2015, at 6:09 , Nicolai Hess <nicolaih...@web.de> 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 <nicolaih...@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=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 >
