-
Notifications
You must be signed in to change notification settings - Fork 301
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#266 - experimentation with OS X paths #286
base: main
Are you sure you want to change the base?
Conversation
…fix failure in ubuntu CI
parse ffprobes -show_packets output
…tion-on-ffmpeg-argument-processor Add fluent configuration of ffoptions per run
…th in PipeArgument
Full stack trace for the
|
@instantiator Which ,NET version did you experiment with? Just curious if any of this got fixed with the .NET 6 release for Mac OS |
Still have this issue (path exceeds the 104 char limit) on .NET 6 when on macOS (running the latest version of macOS). |
I also have the same problem on .Net 6 and on macOS v12.3.1 (the latest one at this moment).
|
Same problem here, would really like to see that fixed... |
Hi Team, same problem here on MacOS M1. I'm working on a ASP.NET Core 3.1 service and was attempting to run FFProbe against a .MOV file:
|
I'm having the same issue here (.NET 6.0.202, macOS Monterey 12.3.1, M1 Macbook Pro) - but only when I run as a regular user:
If I
The actual path being returned from so it looks like macOS is redirecting the pipe path for non-root users and ending up with something that's too long. If I modify the
then I get this instead:
Again, running as |
I think the difference here is that MacOS doesn't accept paths here in user-mode iirc. We had similar problems with shared memory in our project and giving it names instead of paths worked fine. I can dig up the code if anyone wants to know... |
That would be great; at this point, anything that helps shed light on what's happening and how to fix/work around it would be really appreciated! |
Hey, Note that we didn't use any of the dotnet standard things (MemoryMappedFile, etc) since they threw exceptions in netcoreapp3.1 (maybe these work with a newer dotnet). Finally I need to stress that this was about shared memory and not about pipes, but I assumr that these are quite similar in terms of restrictions. Hope that helps a little |
Has this PR still being worked on? There is an issue related to it: #365 |
Named pipe path length limits on OS X mean that default named pipes that are based in
Path.GetTempDir()
are too long. This happens when a named pipe is created with just the pipe name. If a full, rooted, path is provided then that is accepted.The error looks like this:
This PR:
PipeHelpers
PipePath
inPipeArgument
to construct theNamedPipeServerStream
However, although this resolves the issue with the named pipe path length, it leads to another issue.
Test with:
This leads to the following exception:
The
SocketException
indicates that perhaps the named pipe socket is being closed while it is still inAwaitConnection
. Perhaps a connection isn't being properly established. I can't be sure why - although perhaps the issue still lies somewhere in the issue of the pipe name.