File links in Unix VM broken?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

File links in Unix VM broken?

Andreas.Raab
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

Reply | Threaded
Open this post in threaded view
|

Re: File links in Unix VM broken?

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



Reply | Threaded
Open this post in threaded view
|

Re: File links in Unix VM broken?

Alexander Lazarevic'
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
>

Reply | Threaded
Open this post in threaded view
|

Re: File links in Unix VM broken?

Alexander Lazarevic'
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
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: File links in Unix VM broken?

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



Reply | Threaded
Open this post in threaded view
|

Re: File links in Unix VM broken?

Alexander Lazarevic'
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 -
>
>
>