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