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

[Eliot Miranda]

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

> Ok, so what does the cog vm answer?
>

You mean in the dangling link case, right? Important to state the context.

What the unix VM answers, which IMO is wrong.  i.e. in
both platforms//unix/plugins/FilePlugin/sqUnixFile.c and platforms//Mac
OS/plugins/FilePlugin/sqMacUnixFileInterface.c dir_EntryLookup includes:

  if (stat(unixPath, &statBuf) && lstat(unixPath, &statBuf)) {
    return NO_MORE_ENTRIES;
  }

  /* To match the results of dir_Lookup, copy back the file name */
  *nameLength = ux2sqPath(nameString, nameStringLength, name, 256, 0);

  /* last change time */
  *creationDate= convertToSqueakTime(statBuf.st_ctime);
  /* modification time */
  *modificationDate= convertToSqueakTime(statBuf.st_mtime);
 ...

So if the stat fails and lstat succeeds the code answers the info for the
link.  It should read something like

  if (stat(unixPath, &statBuf)) {
      /* If we can lstat the entry exists, but we have no information for
the entry's target so answer a zero date, size, et al */
      if (lstat(unixPath, &statBuf))
           return NO_MORE_ENTRIES;
      memset(&statBuf, 0, sizeof(statBuf));
  }
  ...



> I see that the unix command line says
>
> 12B Sep 20 16:31 /tmp/bar.txt
>>
>>
> which is the meta-data for the alias file, not the target
>
>
> On 2010-09-22, at 1:52 PM, Eliot Miranda wrote:
>
>
>
> 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.
>>
>> 2¢
>> 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
>>
>> ===========================================================================
>>
>>
>>
>>
>>
>
> --
> ===========================================================================
> 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/93e0a42b/attachment.htm