IPCSocket.Path bug

I just found I can’t use an IPCSocket.Path longer than 103 chars.
I thought this bug was already fixed, as reported from feedback://showreport?report_id=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=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 feedback://showreport?report_id=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.

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

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]

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.

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

Thanks Dirk!

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.

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

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=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.