hand-waving `ErrorKind::AddrInUse` is unhelpful

[datner]

Context: latest version 2.2.0, rust 1.79.0, macos ventura 13.6

I'm working on a cross-platform client for some thing or another, and I must use ipc on unix and windows.
In the previous major, getting an AddrInUse meant that the /tmp/whatever file had to be removed and that was it.
This was also expressed in the examples.

Not anymore.
In the current paradigm, once a GenericNamespaced or GenericFilePath is created it is impossible to extract whatever actual path is being used. In practicality, it means 2 things

1. it is impossible to recover from deterministically since neither the dev nor a potential user will have a shred of a clue what should be done, for example what file needs to be removed
2. it is effectively impossible to even brute-force recover from unless set in a loop or recreated internally

  let printname = "myPipe";
  let name = printname.to_ns_name::<GenericNamespaced>()?;

  // Configure our listener...
  let opts = ListenerOptions::new().name(name);

  // ...and create it.
  let listener = match opts.create_tokio() {
      Err(e) if e.kind() == io::ErrorKind::AddrInUse => {
          let path = format!("/tmp/{printname}"); // for example
          let path = Path::new(&path);

          fs::remove_file(&path).expect("..."); // there is no input to which there will be a valid output
          ListenerOptions::new().name(name).create_tokio()? // `opts` cannot be moved, so they are impossible to reuse in this way
      }
      x => x?,
  };

myPipe, /tmp/myPipe. /tmp/myPipe/, /.pipe/myPipe, @myPipe, myPipe.sock, /tmp/myPipe.sock, are all invalid (as in, non-existent) files. This is regardless of usages of GenericNamespaced and GenericFilePath.

It might be that you know exactly what to do to handle the situation, but I have not the slightest of clues and neither did anyone in my team and circle. I've went through the docs, issues, and source files of this project many times over.
I would very much appreciate some sort of guidance

[datner]

Update: It seems that the pipes on macos machines are placed inside the scoped temp files, as in
var/folders/5w/nndj7tgj50dgxl5bb5ybm8pr0000gn/T/<my local pipe>.
I am 99% sure this was not the case before. It used to be in the linux-like /tmp/ folder. This is an issue, because the other users of the pipe target /tmp/ directly. I wish I could do something about it, I can't, so what can I do?

[datner]

Another update:
It appears I was right. Something changed in the impl of the package and it no longer takes the value from env::tmp_dir but rather grab it directly from TMPDIR.
This change was brought on by #62 , but it makes sense only in two circumstances: android because of its encapsulation quirks, and IPC between a process and itself. It is not hyperbole to say that the use case for ipc is mostly between unrelated processes rather than just a very expensive way to invoke a function. This is really frustrating.....

[kotauskas]

It might be that you know exactly what to do to handle the situation

The tests tackle this by using random IDs. For stable locations, though, the generic name types currently don't provide a robust way to handle AddrInUse. I neglected to provide a solution because this is rather opinionated behavior, and I'd yet to form a complete opinion on the optimal way of doing things when 2.2.0 was released. In retrospect, the generic name types should've been documented as less robust.

Something changed in the impl of the package and it no longer takes the value from env::tmp_dir but rather grab it directly from TMPDIR.

Unfortunately, the author of the patch likely did not consider that some platforms that have $TMPDIR set by default also have accessible /tmp, and neither did I. I will revert this shortly.

This is an issue, because the other users of the pipe target /tmp/ directly. I wish I could do something about it, I can't, so what can I do?

If other users of the pipe target a well-specified per-platform path, the FilesystemUdSocket name type is most fitting. Note that the generic name types are simply aliases for platform-specific name types under the hood, and the accidental breaking change is actually inside SpecialDirUdSocket.

[kotauskas]

I have reverted the $TMPDIR change in 2.2.1. SpecialDirUdSocket now points to /data/local/tmp on Android and to /tmp elsewhere.

[datner]

Thank you for the rapid response @kotauskas !
I assume this means that unix-ish system would have /tmp and windows would use \\.\pipe for GenericNamespaced?

Do you have a kofi or some other support mechanism I can reward you with?

[kotauskas]

I currently don't have a donation box because there are difficulties with accepting international payments in my country that I've yet to navigate. I may set one up later, though.

[datner]

I neglected to provide a solution because this is rather opinionated behavior

Thats fair, I am ok with needing to handle this on my own. The issue was mostly that from Name<'{error}> I can't ever get a &Path, PathBuf, or even some String or &str.. Given those I think you might not need to think of a universal way

[datner]

Ah, I am very familiar with those kinds of setbacks. My sympathies

[burningtnt]

I encounter this issue when developing applications with interproces too.
Is it the only solution to manually delete /tmp/{printname}?

[trepidacious]

Could there just be a simple built-in way to delete the associated file, if there is one? Looking at the code, the existing reclaim guard drop knows how to get the file that needs deleting - seems like this could be exposed on Name, e.g. delete_file_if_exists, or associated_file returning an optional path?

Or alternatively it could be an option in ListenerOptions to attempt to delete any existing file rather than returning AddrInUse? This would be the easiest for my use case, where I want to implement the normal logic for enforcing a single instance of my application but still allow for opening files in that instance via double-click. So if the application is already running I would use IPC to send the filename in the args of the second instance, to the first instance. At the point I try to listen for IPC I've already established (by whatever method) that I don't think there is already an instance of the application running, so I definitely want to delete any existing file. Of course with the race conditions you mention I may be wrong about being the only instance, but this is still better than just making it impossible to use IPC if a stale file is ever left in place?

At the moment, it seems like the "delete the file yourself" approach is very risky/unfriendly - users of the library need to read through the code to work out what file to delete on any given OS, if they get it right then it's the same as a built-in method in the library, except that if the library changes code breaks, and if they get it wrong it's a hard-to-test bug.

If the method can't be built-in, could the example be extended to show the recommended way to work out what file to delete?

[vrurg]

Or alternatively it could be an option in ListenerOptions to attempt to delete any existing file rather than returning AddrInUse?

This is a very bad idea. Consider accidentally started second server that would want to bind to the same socket. Sometimes it's no problem, sometimes it can be disastrous!

associated_file returning an optional path?

I'd like to see a method like this. It has to be up to the dev to decide how to handle the AddrInUse case.