Smalltalk › Squeak › Squeak VM

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Mariano Martinez Peck

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

---------- Forwarded message ----------
From: Sven Van Caekenberghe <[hidden email]>
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 <[hidden email]>

http://code.google.com/p/pharo/issues/detail?id=2982

Sven

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

johnmci

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

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 <[hidden email]>
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 <[hidden email]>

http://code.google.com/p/pharo/issues/detail?id=2982

Sven

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

===========================================================================

John M. McIntosh <[hidden email]> Twitter: squeaker68882

Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com

===========================================================================

smime.p7s (5K) Download Attachment

Eliot Miranda-2

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

On Tue, Sep 21, 2010 at 10:33 PM, John M McIntosh <[hidden email]> 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 <[hidden email]>
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 <[hidden email]>

http://code.google.com/p/pharo/issues/detail?id=2982

Sven

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
===========================================================================

John M. McIntosh <[hidden email]> Twitter: squeaker68882

Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com

===========================================================================

johnmci

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

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 <[hidden email]> 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 <[hidden email]>
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 <[hidden email]>

http://code.google.com/p/pharo/issues/detail?id=2982

Sven

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
===========================================================================

John M. McIntosh <[hidden email]> Twitter: squeaker68882

Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com

===========================================================================

===========================================================================

John M. McIntosh <[hidden email]> Twitter: squeaker68882

Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com

===========================================================================

smime.p7s (5K) Download Attachment

Eliot Miranda-2

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

On Wed, Sep 22, 2010 at 1:01 PM, John M McIntosh <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
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 <[hidden email]>

http://code.google.com/p/pharo/issues/detail?id=2982

Sven

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
===========================================================================

John M. McIntosh <[hidden email]> Twitter: squeaker68882

Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com

===========================================================================
--
===========================================================================

John M. McIntosh <[hidden email]> Twitter: squeaker68882

Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com

===========================================================================

johnmci

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

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
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 <[hidden email]>

http://code.google.com/p/pharo/issues/detail?id=2982

Sven

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
===========================================================================

John M. McIntosh <[hidden email]> Twitter: squeaker68882

Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com

===========================================================================
--
===========================================================================

John M. McIntosh <[hidden email]> Twitter: squeaker68882

Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com

===========================================================================

===========================================================================

John M. McIntosh <[hidden email]> Twitter: squeaker68882

Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com

===========================================================================

smime.p7s (5K) Download Attachment

Eliot Miranda-2

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

On Wed, Sep 22, 2010 at 3:45 PM, John M McIntosh <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
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 <[hidden email]>

http://code.google.com/p/pharo/issues/detail?id=2982

Sven

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
===========================================================================

John M. McIntosh <[hidden email]> Twitter: squeaker68882

Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com

===========================================================================
--
===========================================================================

John M. McIntosh <[hidden email]> Twitter: squeaker68882

Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com

===========================================================================
--
===========================================================================

John M. McIntosh <[hidden email]> Twitter: squeaker68882

Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com

===========================================================================