Can't open file if the file is being used by a program on Windows

[Legend-Master]

When opening a file that is being used by a program, open will fail with ok result

It's common to open a log file that is still being used by the program

We currently spawn a cmd and run start command with it, can we migrate it to use Windows APIs instead like what opener does?

[Byron]

Thanks for bringing this up, I wasn't aware.

Does opener work where open doesn't in this particular case?

Besides that, by now most of the API surface of this crates relies on the idea that a program is spawned (which then has advantages when integrating with async runtimes), which means that deviating from that can't work anymore. Unless, of course, and entirely disjoint API is added just for windows that is the same as opener. And if that would be done, it feels that opener should be used instead.

It's good to see that both crates have different approaches to solve the same problems, both with their own upsides and downsides, which hopefully covers that surprisingly complex space of 'cross-platform opening of things' pretty well.

What do you think?

[Legend-Master]

opener uses ShellExecute, and it works in this case

https://github.com/Seeker14491/opener/blob/c4ad5579fe1cf53337c2ce0c4f1c118d7df34349/opener/src/windows.rs#L31
https://microsoft.github.io/windows-docs-rs/doc/windows/Win32/UI/Shell/fn.ShellExecuteW.html
https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecutew

I would expect open to work in this case, and using ShellExecute is a possible fix for this problem

My current use case is I'm trying to use tauri shell plugin (which uses open) to open the app log file, and it fails silently

It's good to see that both crates have different approaches to solve the same problems, both with their own upsides and downsides

I agree, maybe I should try push tauri team to use opener for this special case, open is purely command based, adding an platform specific API call seem to be a bit too invasive

[Byron]

Yes, if the tauri team doesn't use the Command based API here for async integration, I think they should have no problem to switch to opener if that's more reliable on Windows. open might have played itself into a corner on this platform due to the assumption the command-line can be made to work the same on Windows as the API.

Probably tauri can always spawn a new blocking task for opening when using opener as well, so technically they should have no problem.

Even if you decide to close this issue, I'd appreciate if you would link or share the respective issue in tauri should you create it, as I am keen to learn the resolution they come up with.

Thank you.

[Legend-Master]

I'll open an issue on https://github.com/tauri-apps/plugins-workspace when I get the time and post a link here

I think tauri currently doesn't use async for open, so that's probably not a concern

Since opener doesn't have the ability to specify open program, maybe we'll end up using both, or maybe they would decide to not support open with specific program

Thank you for the quick response 😀

[Legend-Master]

tauri-apps/plugins-workspace#1003