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 -
> 
> 
>