Opening attachments with commands which use a subshell are racy?

[romanofski]

Describe the bug
I've seen instances in which opening attachments with firefox end up with an error: the file can not be opened because it can not be found. This seems to be happening at random, although opening the same attachment a second time seems to work (I have not determined what the success rate is).

One thing however which sticks out is that the typical firefox program on Linux is a bash script. Purebred runs the invocation of Firefox in a shell itself. Commands like elinks seem to not have any trouble. My suspicion is, that the shell itself returns and therefore causes Purebred to close and remove the temporary file.

To Reproduce
Steps to reproduce the behavior:

1. Open an e-mail.
2. See list of attachments
3. Pick an HTML attachment and open it with firefox (should be a shell script)
4. See error

Expected behavior
No random failures due to the removal of the temporary file.

Screenshots
none

Additional context
Not sure what a good solution here is other than not remove the temporary file when the sub process has exited.

[frasertweedale]

Yep, for sure this is the child process exiting after signalling some other process (i.e. the already-running firefox instance) to open the file.

We need a knob that says whether or not to delete the file after child process returns.

[romanofski]

After merging #275 I think fixing this item could also add a bit of cleanup for our open and pipe actions. I envision using a data type which can do a bracket style side effect. I haven't thought it through how exactly it will look like and how to incorporate the recent work on #269 but I hope it can be used to cleanup the duplication with invokeEditor, pipeCommand and openCommand.

[romanofski]

I've investigated the problem a bit further and stumbled over a script which employs inotify to watch when the file is closed by the child process. I suppose just watching if the file is closed will cause the same problem, but knowing about inotify I suppose an action could register a handler upon opening the file which removes it on a subsequent close.

The down side of this is, that it only works on Linux (or systems which support inotify) and therefore would restrict our portability (if that's even a thing).

I guess keeping the temporary file for now is the way to go and thinking about further fine grained management could be a thing if the need arises.

[frasertweedale]

Yikes, let's not go there. We just have a two-state knob, delete-after-child-termintes or not. The "not" case comes with the obvious caveat, and we move on.