File links in Unix VM broken?
Locked
 
|
Hi -
I had an interesting problem today. I had created a directory with a plain file like /foo/bar/plainfile and then added a subdirectory with a relative link to that file: /foo/bar/baz/link -> ../plainfile The link would be listed in the the directory listing primitives but would fail to open (although bash and any other unix tool would work just fine with it). When I played around a little more I found that the VM was trying to open /foo/plainfile instead of /foo/bar/plainfile (placing a test file in the location confirmed that) so it seems as if the Unix file code doesn't deal correctly with "up links" (going one hop too many). Any ideas how to fix that? I can work around it easy enough now that I know it but it'd be good if the problem could be fixed in general. Cheers, - Andreas |
|
|
Well did you look into
sqFileOpen in sqFilePluginBasicPrims.c at the point where it does the fopen(cFileName, ".... what does it think cFileName is? mind don't forget it takes whatever squeak hands it and grinds thru sqGetFilenameFromString() before giving to fopen( See sqUnixMain.c On Nov 7, 2007, at 8:05 PM, Andreas Raab wrote: > Hi - > > I had an interesting problem today. I had created a directory with > a plain file like > > /foo/bar/plainfile > > and then added a subdirectory with a relative link to that file: > > /foo/bar/baz/link -> ../plainfile > > The link would be listed in the the directory listing primitives > but would fail to open (although bash and any other unix tool would > work just fine with it). When I played around a little more I found > that the VM was trying to open /foo/plainfile instead of /foo/bar/ > plainfile (placing a test file in the location confirmed that) so > it seems as if the Unix file code doesn't deal correctly with "up > links" (going one hop too many). Any ideas how to fix that? I can > work around it easy enough now that I know it but it'd be good if > the problem could be fixed in general. > > Cheers, > - Andreas > -- ======================================================================== === John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
Re: File links in Unix VM broken?
|
|
In reply to this post by Andreas.Raab
I did a quick check with strace -e trace=file squeakvm ...
Seems to work for the vm I'm using[1]. (Although the link also had the name plainfile) lstat64("/tmp/foo/baz/plainfile", {st_mode=S_IFLNK|0777, st_size=12, ...}) = 0 readlink("/tmp/foo/baz/plainfile", "../plainfile", 4096) = 12 lstat64("../plainfile", {st_mode=S_IFREG|0644, st_size=5, ...}) = 0 open("../plainfile", O_RDONLY) = 8 Alex [1] VM from Matej squeak-vm package: 3.9-8 #1 Fri Sep 7 00:19:56 CEST 2007 gcc 4.1.2 Squeak3.9alpha of 4 July 2005 [latest update: #7021] Linux debian 2.6.18-5-686 #1 SMP Sun Aug 12 21:57:02 UTC 2007 i686 GNU/Linux Andreas Raab schrieb: > Hi - > > I had an interesting problem today. I had created a directory with a > plain file like > > /foo/bar/plainfile > > and then added a subdirectory with a relative link to that file: > > /foo/bar/baz/link -> ../plainfile > > The link would be listed in the the directory listing primitives but > would fail to open (although bash and any other unix tool would work > just fine with it). When I played around a little more I found that the > VM was trying to open /foo/plainfile instead of /foo/bar/plainfile > (placing a test file in the location confirmed that) so it seems as if > the Unix file code doesn't deal correctly with "up links" (going one hop > too many). Any ideas how to fix that? I can work around it easy enough > now that I know it but it'd be good if the problem could be fixed in > general. > > Cheers, > - Andreas > |
Re: File links in Unix VM broken?
|
|
Ok, this only works if squeaks gets launched with the subdirectory as
the current directory. Launched from another directory I get the same problem as you do. Alexander Lazarevic' schrieb: > I did a quick check with strace -e trace=file squeakvm ... > Seems to work for the vm I'm using[1]. (Although the link also had the > name plainfile) > > lstat64("/tmp/foo/baz/plainfile", {st_mode=S_IFLNK|0777, st_size=12, > ...}) = 0 > readlink("/tmp/foo/baz/plainfile", "../plainfile", 4096) = 12 > lstat64("../plainfile", {st_mode=S_IFREG|0644, st_size=5, ...}) = 0 > open("../plainfile", O_RDONLY) = 8 > > Alex > > [1] VM from Matej squeak-vm package: > 3.9-8 #1 Fri Sep 7 00:19:56 CEST 2007 gcc 4.1.2 > Squeak3.9alpha of 4 July 2005 [latest update: #7021] > Linux debian 2.6.18-5-686 #1 SMP Sun Aug 12 21:57:02 UTC 2007 i686 GNU/Linux > > > Andreas Raab schrieb: >> Hi - >> >> I had an interesting problem today. I had created a directory with a >> plain file like >> >> /foo/bar/plainfile >> >> and then added a subdirectory with a relative link to that file: >> >> /foo/bar/baz/link -> ../plainfile >> >> The link would be listed in the the directory listing primitives but >> would fail to open (although bash and any other unix tool would work >> just fine with it). When I played around a little more I found that the >> VM was trying to open /foo/plainfile instead of /foo/bar/plainfile >> (placing a test file in the location confirmed that) so it seems as if >> the Unix file code doesn't deal correctly with "up links" (going one hop >> too many). Any ideas how to fix that? I can work around it easy enough >> now that I know it but it'd be good if the problem could be fixed in >> general. >> >> Cheers, >> - Andreas >> > |
Re: File links in Unix VM broken?
|
|
In reply to this post by Andreas.Raab
On Nov 8, 2007, at 5:05 , Andreas Raab wrote:
> Hi - > > I had an interesting problem today. I had created a directory with > a plain file like > > /foo/bar/plainfile > > and then added a subdirectory with a relative link to that file: > > /foo/bar/baz/link -> ../plainfile > > The link would be listed in the the directory listing primitives > but would fail to open (although bash and any other unix tool would > work just fine with it). When I played around a little more I found > that the VM was trying to open /foo/plainfile instead of /foo/bar/ > plainfile (placing a test file in the location confirmed that) so > it seems as if the Unix file code doesn't deal correctly with "up > links" (going one hop too many). Any ideas how to fix that? I can > work around it easy enough now that I know it but it'd be good if > the problem could be fixed in general. I've seen this problem, too, but never took time to investigate. - Bert - |
Re: File links in Unix VM broken?
|
|
The problem is in sqUnixmain.c in sqGetFilenameFromString:
If resolveAlias is true, the filename will be the content of the symbolic link (../plainfile) instead of the link. After removing the alias handling the link can be viewed in Squeak. I don't know when this alias handling makes sense on linux, after all the comment in interp.c says /Note the resolveAliases flag - this is an awful artefact of OSX and Apples demented alias handling. When opening a file, the flag must be true, when closing or renaming it must be false. Sigh/ Alex Bert Freudenberg schrieb: > On Nov 8, 2007, at 5:05 , Andreas Raab wrote: > >> Hi - >> >> I had an interesting problem today. I had created a directory with a >> plain file like >> >> /foo/bar/plainfile >> >> and then added a subdirectory with a relative link to that file: >> >> /foo/bar/baz/link -> ../plainfile >> >> The link would be listed in the the directory listing primitives but >> would fail to open (although bash and any other unix tool would work >> just fine with it). When I played around a little more I found that >> the VM was trying to open /foo/plainfile instead of /foo/bar/plainfile >> (placing a test file in the location confirmed that) so it seems as if >> the Unix file code doesn't deal correctly with "up links" (going one >> hop too many). Any ideas how to fix that? I can work around it easy >> enough now that I know it but it'd be good if the problem could be >> fixed in general. > > I've seen this problem, too, but never took time to investigate. > > - Bert - > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |