IPCSocket.Path bug

General
1

I just found I can’t use an IPCSocket.Path longer than 103 chars.
I thought this bug was already fixed, as reported from <https://xojo.com/issue/22697>, but the problem is still present and the docs says this.

Now the problem is that using a path into temporary folder sometimes is very long and it’s very easy to occur into this limitation.
Example temp path on Mac:
/private/var/folders/zz/_k7x4ht97pg1dv_wv64t59ph0000gp/T/TemporaryItems/
which is 72 char long.
Following the suggestion of using the bundle id for the socket name, it’s very easy to exceed 103 chars.

2

[quote=122725:@Massimo Valle]I just found I can’t use an IPCSocket.Path longer than 103 chars.
I thought this bug was already fixed, as reported from <https://xojo.com/issue/22697>, but the problem is still present and the docs says this.

Now the problem is that using a path into temporary folder sometimes is very long and it’s very easy to occur into this limitation.
Example temp path on Mac:
/private/var/folders/zz/_k7x4ht97pg1dv_wv64t59ph0000gp/T/TemporaryItems/
which is 72 char long.
Following the suggestion of using the bundle id for the socket name, it’s very easy to exceed 103 chars.[/quote]

This is a limitation of the OS and nothing can be done about it.

3

Out of curiosity, exactly the same limitation exists for Windows and OS X?

4

No, the limitation is OS specific. Windows has a completely different implementation that I don’t know too much about offhand, but OS X and Linux use Unix domain sockets. Here is bit of relevant documentation about domain sockets:

[quote]The size of sun_path has intentionally been left undefined. This is because different implementations use different sizes. For example, 4.3 BSD uses a size of 108, and 4.4 BSD uses a size of 104. Since most implementations originate from BSD versions, the size is typically in the range 92 to 108.

Applications should not assume a particular length for sun_path or assume that it can hold {_POSIX_PATH_MAX} characters (255).[/quote]

5

Thanks for the info Joe.
Indeed knowing a little bit more about the Windows implementation would be useful. I have a problem on a Windows machine where I can’t use anymore a file name (the socket is not created). just changing the file name (same length) it works, but I can’t change the name due to other dependencies.

6

IPCSocket on Windows is implement as a TCPSocket on localhost.
See http://forums.realsoftware.com/viewtopic.php?f=2&t=2735

7

Thanks Dirk!

8

This comes up often, and I’m always confused. I never use a “real” file for the IPCSocket path, but a fake-ish path (/tmp/myapp/foobar) and it’s worked great for years on mac & windows. The documentation seems to suggest otherwise, though.

9

On OS X and Linux, these are actual entities in the filesystem (but not on disk).

10

By “Fake-ish” I mean : I’ve just set a string, such as “/tmp/myapp/foobaroptoins” and used this for OSX and Win32 and never ever cared about whether that path was valid (e.g., I don’t worry about whether sub-folders exist, or if the end path already exists). I just plow on ahead. Works great.

The docs seem to suggest a fragility to the path string, that, IMHO, has led others astray?

11

[quote=123055:@Michael Diehr]By “Fake-ish” I mean : I’ve just set a string, such as “/tmp/myapp/foobaroptoins” and used this for OSX and Win32 and never ever cared about whether that path was valid (e.g., I don’t worry about whether sub-folders exist, or if the end path already exists). I just plow on ahead. Works great.

The docs seem to suggest a fragility to the path string, that, IMHO, has led others astray?[/quote]

I have had success in both desktop and web apps with specialfolder.temporary.child(“myipcfile.xyz”)

Actually implemented shell in a web app that way.