issue with large file path on windows
Locked
12
12
Re: [Vm-dev] issue with large file path on windows
 
|
Hi David,
On Tue, Sep 15, 2015 at 5:45 AM, Esteban Lorenzano <[hidden email]> wrote:
I agree with Esteban. IMO, the model of files that the FilePlugin provides access to can and should be a superset of facilities. By not supporting facilities such as permissions or symbolic links or active mount-points we hobble our core file functionality and that makes us a very weak scripting platform. Putting these facilities in add-on packages makes configuration more difficult and means that an elegant implementation in the core file classes, with fallbacks for platforms that don't support the concepts, is very difficult. If we want to support unix-style scripting in Pharo and Squeak (and I think we very much do; there are many areas out there where good scripting is essential) then we need a better File model, and that means not just getting rid of FileDirectory et al, it also means providing the right infrastructure in the FilePlugin, and that means extensions like the one the Pharo VM folks made. Indeed they haven't gone nearly far enough IMO.
_,,,^..^,,,_ best, Eliot |
Re: [Vm-dev] issue with large file path on windows
|
|
On Tue, Sep 15, 2015 at 10:45:16AM -0700, Eliot Miranda wrote:
> > Hi David, > > On Tue, Sep 15, 2015 at 5:45 AM, Esteban Lorenzano <[hidden email]> > wrote: > > > > > > On 15 Sep 2015, at 14:13, David T. Lewis <[hidden email]> wrote: > > > > > > > > > On Tue, Sep 15, 2015 at 11:40:48AM +0200, Esteban Lorenzano wrote: > > >> > > >> Pharo uses them. > > >> > > >> Posix permissions are useful for both linux and mac. > > >> Windows uses also the posix permissions that came with MinGW??? I do > > not think they are useful but we provide them anyway :) > > > > > > > > > Posix permissions are based on Unix, and are very platform specific. The > > > Windows equivalents are semantically different, and other operating > > systems > > > may exist that are not Unix based at all. > > > > > > IMO, platform specific functions should go into separate plugins, and not > > > in FilePlugin. > > > > well, I disagree :) > > I do not find this approach practical??? because in general, there is no > > other systems that may exist using other permissions than POSIX. Except > > Windows, of course, but even for windows, there are compatibility layers > > that we can use. > > In the case of the FilePlugin extensions, we choose to stay POSIX because > > in general, as its been said before, the job of a virtual machine is been > > virtual: to provide an ???abstract machine??? common for everything in the > > image. I???m not saying that this is possible and even desirable in all > > cases, but it should be something to think about. > > In that case, we could design a common file permissions different to the > > one of Windows and different to POSIX, but I think POSIX does the job just > > fine. > > > > Also, the choice was: POSIX or nothing (because we didn???t have anything > > before). > > I would be very happy if we agree in a better solution, and we implement > > it. > > But in the mean time, a not perfect solution is better than none. > > > > I agree with Esteban. IMO, the model of files that the FilePlugin provides > access to can and should be a superset of facilities. By not supporting > facilities such as permissions or symbolic links or active mount-points we > hobble our core file functionality and that makes us a very weak scripting > platform. Putting these facilities in add-on packages makes configuration > more difficult and means that an elegant implementation in the core file > classes, with fallbacks for platforms that don't support the concepts, is > very difficult. I do not intend to suggest that these things are not wonderful and good and worthy of being done. What I said is that they should not be put into FilePlugin. Yes it is more difficult to implement features like this in packages, but with all due respect it's not all *that* terribly hard. And I think the too much work argument does not hold up when we are talking about something like FilePlugin that effectively defines minimal core functionality required to bring up an image on a new platform. > > If we want to support unix-style scripting in Pharo and Squeak (and I think > we very much do; there are many areas out there where good scripting is > essential) then we need a better File model, and that means not just > getting rid of FileDirectory et al, it also means providing the right > infrastructure in the FilePlugin, and that means extensions like the one > the Pharo VM folks made. Indeed they haven't gone nearly far enough IMO. Again, I am not saying that these things should not be done. Just that with respect to platform-specific features that can only ever work on a Unix based system, allowing these to creep into the feature set of base system does not seem like a very good idea to me. That's all I am saying. Dave |
Re: [Vm-dev] Re: issue with large file path on windows
|
|
In reply to this post by Nicolai Hess
2015-09-15 9:19 GMT+02:00 Nicolai Hess <[hidden email]>:
OK, these changes are now in pharos vm repository, .... but I just found another issue with long paths, squeak and pharo: This is a path from one github repository based package u:\pharo_images\images\Pharo 5.0 (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st Yes, pathlength is 282! But I think the problem is not the overall path name, but the length of the filename. On squeak, you can open and browse the parent directory in a FileList and even show the contents of the contained files. On Pharo, this does not work, because Pharos FileList uses a different method for accessing the file attributes. (the difference is, we call dir_EntryLookup, whereas (most) of Squeaks FileList methods just call dir_Lookup). But there are some methods in Squeak that call dir_EntryLookup and those are failing too. For example: "Creating a Stream and reading the contents works" (FileStream fileNamed:'u:\pharo_images\images\Pharo 5.0 (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st') contents."Creating a Stream and accessing the directory entry does not work" (FileStream fileNamed:'u:\pharo_images\images\Pharo 5.0 (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st') directoryEntry " -> Error: file not in directory: initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st" nicolai |
Re: [Vm-dev] Re: issue with large file path on windows
|
|
Hi Nicolai, I have to say that the problem lies with the git integration. The length of Smalltalk selectors is effectively unlimited and the language encourages Kong descriptive names. Many (most?) unixes have a limitation of 256 characters in any path element and a PATH_MAX that may be as little as 1024. So the current architecture is, for me, way too close to implementation limits. IMO a far better design would be to use protocol names, all methods per protocol, eg Object.accessing or two files per class (instance & class side) with methods ordered by selector. Either of those, but especially the last, should give good diff results in git but be well away from the implementation limit. The one method per file, selector as file name approach is asking for trouble. _,,,^..^,,,_ (phone)
|
Re: [Vm-dev] Re: issue with large file path on windows
|
|
Hi Eliot,
I believe everytime this comes up, it is not an issue of filetree making files too long for the filesystem, it is an issue of Pharo not being able to read or write a valid file for the filesystem. It is easy to "fix" filetree to workaround bugs in FilePlugin on Windows, but I'm not sure it's the right way to solve the problem ;) Simply because someone will hit it when reading a random, valid file one day. Thierry Le 13/10/2015 01:01, Eliot Miranda a écrit : > Hi Nicolai, > > I have to say that the problem lies with the git integration. The > length of Smalltalk selectors is effectively unlimited and the language > encourages Kong descriptive names. Many (most?) unixes have a > limitation of 256 characters in any path element and a PATH_MAX that may > be as little as 1024. So the current architecture is, for me, way too > close to implementation limits. IMO a far better design would be to use > protocol names, all methods per protocol, eg Object.accessing or two > files per class (instance & class side) with methods ordered by > selector. Either of those, but especially the last, should give good > diff results in git but be well away from the implementation limit. The > one method per file, selector as file name approach is asking for trouble. > > _,,,^..^,,,_ (phone) > > On Oct 12, 2015, at 3:04 PM, Nicolai Hess <[hidden email] > <mailto:[hidden email]>> wrote: > >> >> >> 2015-09-15 9:19 GMT+02:00 Nicolai Hess <[hidden email] >> <mailto:[hidden email]>>: >> >> >> >> 2015-09-14 23:10 GMT+02:00 Eliot Miranda <[hidden email] >> <mailto:[hidden email]>>: >> >> >> Thanks Nicolai, that's great! I'll merge in your changes. >> Which files do I need to look at? >> >> >> I changed (removed my code, added Marcels) >> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c >> platforms/win32/vm/sqWin32.h >> platforms/win32/vm/sqWin32Directory.c >> >> I added (should be the same as in squeak vm repository) >> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c >> >> >> But my changes only about that code that already is in squeaks >> repository. >> >> If we want to merge some of the pharo-vm code into squeaks branch, we >> first need to wrap that code with some #ifdefs >> >> (For the win32 file/directory stuff, this would be code in >> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c >> platforms/win32/vm/sqWin32.h >> platforms/win32/vm/sqWin32Directory.c >> and >> platforms/Cross/plugins/FilePlugin/FilePlugin.h) >> >> Maybe Estaban should look at this, and tell which path he would >> follow to >> merge those changes. >> >> >> OK, these changes are now in pharos vm repository, .... >> >> >> but I just found another issue with long paths, squeak and pharo: >> >> This is a path from one github repository based package >> >> u:\pharo_images\images\Pharo 5.0 >> (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st >> >> Yes, pathlength is 282! But I think the problem is not the overall >> path name, but the length of the filename. >> >> On squeak, you can open and browse the parent directory in a FileList >> and even show the contents of the contained files. >> On Pharo, this does not work, because Pharos FileList uses a different >> method for accessing the file attributes. >> (the difference is, we call dir_EntryLookup, whereas (most) of Squeaks >> FileList methods just call dir_Lookup). >> >> But there are some methods in Squeak that call dir_EntryLookup and >> those are failing too. >> >> For example: >> >> "Creating a Stream and reading the contents works" >> (FileStream fileNamed:'u:\pharo_images\images\Pharo 5.0 >> (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st') >> contents. >> >> "Creating a Stream and accessing the directory entry does not work" >> (FileStream fileNamed:'u:\pharo_images\images\Pharo 5.0 >> (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st') >> directoryEntry >> " -> Error: file not in directory: >> initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st" >> >> >> nicolai >> >> |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |