[Vm-dev] Fwd: [Pharo-project] Issue 2982: DirectoryEntry on Cog VM OSX does not follow symlinks for determining file size

Eliot Miranda eliot.miranda at gmail.com
Wed Sep 22 20:52:31 UTC 2010


On Wed, Sep 22, 2010 at 1:01 PM, John M McIntosh <
johnmci at smalltalkconsulting.com> wrote:

> Although the behaviour aspect is a concern.
>
> IE open the target file, rename only the alias, delete only the alias.
>
> The question was more what should I return for the alias create, mod, and
> file size.
> The data from the alias file, or the data from the target file.
>
> My point was in OS-X, aka unix like operating systems it returns the
> meta-data from the alias file.
>

It should answer the metadata for the target.  Answering the metadata for
the link/alias should require special action.


> The complaint was under Carbon OS-9 it would return the meta-data from the
> target file, so the behaviour is different.
>

The Carbon behavior is IMO correct.  For symbolic links to behave like
transparent links systems need to hide their existence when interacting with
the file system in a conventional manner.  Not doing so renders symbolic
links useless.  It is useful to be able to see symbolic links and aliases
and so it is useful to add unconventional means to discover thise
links/aliases. But for the links to function like links Squeak should
indirect through them conventionally.

best
Eliot


>
>
> On 2010-09-21, at 11:13 PM, Eliot Miranda wrote:
>
>
>
> On Tue, Sep 21, 2010 at 10:33 PM, John M McIntosh <
> johnmci at smalltalkconsulting.com> wrote:
>
>>
>> Ok, well someone needs to decide what the acceptable behaviour is.
>>
>
> If attempting to ope the link opens the target then (of course) the
> acceptable behaviour is to show the size of the target. In Unix one has to
> take special action to see the link (use a special argument to ls, use
> lstat, use readlink, etc).  Likewise with the VM all standard operations
> should follow the link and special action be required to see the link.
>  Links without targets are a grey area in which I think it better to fail
> safe.  e.g. the size of a targetless link should be 0, not the size of the
> link.  An attempt to open a targetless link will not answer the link itself
> (fopen in the standard FilePlugin implementation will answer an error), so
> answering the size of the link is inconsistent with the implementation of
> the FilePlugin.
>
>> Eliot
>
>
>> $ ls -lah /tmp/*.txt
>> lrwxr-xr-x  1 sven  wheel    12B Sep 20 16:31 /tmp/bar.txt -> /tmp/foo.txt
>> -rw-r--r--  1 sven  wheel    36B Sep 20 16:30 /tmp/foo.txt
>>
>>
>> /tmp/bar.txt  is 12 bytes
>>
>> /tmp/foo.txt  is 36  bytes
>>
>>
>> We show that....
>>
>>
>> On 2010-09-20, at 8:18 AM, Mariano Martinez Peck wrote:
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Sven Van Caekenberghe <sven at beta9.be>
>> Date: Mon, Sep 20, 2010 at 4:57 PM
>> Subject: [Pharo-project] Issue 2982: DirectoryEntry on Cog VM OSX does not
>> follow symlinks for determining file size
>> To: Pharo Development <Pharo-project at lists.gforge.inria.fr>
>>
>>
>> http://code.google.com/p/pharo/issues/detail?id=2982<http://code.google.com/p/pharo/issues/?id=2982>
>>
>> Sven
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>>   --
>>
>> ===========================================================================
>> John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:
>>  squeaker68882
>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>>
>> ===========================================================================
>>
>>
>>
>>
>>
>>
>
> --
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:
>  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100922/038715c4/attachment-0001.htm


More information about the Vm-dev mailing list