Fwd: [Pharo-project] Issue 2982: DirectoryEntry on Cog VM OSX does not follow symlinks for determining file size
---------- Forwarded message ---------- From: Sven Van Caekenberghe sven@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@lists.gforge.inria.fr
http://code.google.com/p/pharo/issues/detail?id=2982
Sven
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ok, well someone needs to decide what the acceptable behaviour is.
$ 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@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@lists.gforge.inria.fr
http://code.google.com/p/pharo/issues/detail?id=2982
Sven
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Tue, Sep 21, 2010 at 10:33 PM, John M McIntosh < johnmci@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@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@lists.gforge.inria.fr
http://code.google.com/p/pharo/issues/detail?id=2982http://code.google.com/p/pharo/issues/?id=2982
Sven
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
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. The complaint was under Carbon OS-9 it would return the meta-data from the target file, so the behaviour is different.
On 2010-09-21, at 11:13 PM, Eliot Miranda wrote:
On Tue, Sep 21, 2010 at 10:33 PM, John M McIntosh johnmci@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@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@lists.gforge.inria.fr
http://code.google.com/p/pharo/issues/detail?id=2982
Sven
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Wed, Sep 22, 2010 at 1:01 PM, John M McIntosh < johnmci@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@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@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@lists.gforge.inria.fr
http://code.google.com/p/pharo/issues/detail?id=2982http://code.google.com/p/pharo/issues/?id=2982
Sven
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
=========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Ok, so what does the cog vm answer? 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@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@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@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@lists.gforge.inria.fr
http://code.google.com/p/pharo/issues/detail?id=2982
Sven
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Wed, Sep 22, 2010 at 3:45 PM, John M McIntosh < johnmci@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@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@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@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@lists.gforge.inria.fr
http://code.google.com/p/pharo/issues/detail?id=2982http://code.google.com/p/pharo/issues/?id=2982
Sven
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
=========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================
--
=========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
John M McIntosh -
Mariano Martinez Peck