Re: [lmi] [low priority] Failing unique_filepath() test on Linux

[Greg Chicares]

On 2015-03-01 02:03, Vadim Zeitlin wrote:
> 
>  While testing that my miscellaneous change didn't break anything, I ran
> all the tests not only under MSW, but also under Linux and although I was
> prepared to see some failures, I was surprised to see them in the
> path_utility_test, so I looked closer at what goes on in it. And it turns
> out that test_unique_filepath_with_normal_filenames() relies on the fact
> that keeping a file open for writing prevents it from being deleted -- but
> this is simply not the case under the Unix systems where this just keeps
> the actual inode alive, but doesn't prevent the program (or anybody else)
> from unlinking it.

Documentation for unique_filepath():

/// Motivating example. Suppose an illustration is created from input
/// file 'foo.in', and output is to be saved in a pdf file. A natural
/// name for the pdf file would be 'foo.pdf'. If a file with that
/// exact name already exists, it should normally be erased, and its
/// name reused: that's what an end user would expect. But that's not
/// possible of 'foo.pdf' is already open in some viewer that locks it
        s/of/if/
/// against modification; in that case, a distinct new name must be
/// devised.

Input files for lmi are developed iteratively. We start with something that
seems reasonable, run the calculations to see how they come out, and then
refine the input to get closer to the output we want. The calculation summary
is convenient for this--it's built in, it's automatic, and it's fast--but
sometimes we use "File | Print preview" as a guide to further iterative
refinement of the input.

I once used a "file commander" program that didn't offer a simple "open file"
command. Instead, it had two commands: "edit file", which locked the file for
exclusive write access, and "browse file", which didn't. In this lmi use case,
we want to "browse" the pdf file. End users normally should not modify a pdf
file that lmi has created. But they may want to view successive versions of
printable output that result from successive lmi input modifications.

Most msw end users have this "viewer that locks it against modification".
It doesn't want to behave as a "browser". It wants to be an editor; but,
again, end users normally don't want to, and shouldn't, use it that way, so
we need to work around this problem for them. We'd rather just overwrite the
last 'foo.pdf' we created, but an ill-behaved program gets in our way, so we
support our end users by unique-ifying the file name.

A similar problem arises with an ill-behaved spreadsheet that's popular in
the msw world; we work around it the same way. I use well-behaved "browsers"
for pdf and spreadsheet output, so I don't have this problem myself. I guess
you're saying that *nix systems don't allow this sort of misbehavior; in
that case, we don't need to work around it, so...

>  So the reason for the test failure is clear, but not so much the solution
> to it. Disabling the tests under non-MSW platforms is an obvious option,

Sounds good. It's an msw-specific workaround, so test it only under msw.

> but I wonder if unique_path() behaviour is actually correct under Linux,
> i.e. whether we really want to unlink the currently opened file, even if we
> can. Perhaps we should either really prevent it from being deleted or check
> if it is still being used in some other way?

No, I really think we just want to overwrite the file, without regard to
what may happen to its previous contents.

Open two terminals, and consider:

  In terminal one:
$nano ~/eraseme
  [change "hello" to "goodbye", then ^O^X to save and exit]

  In terminal two:
$less ~/eraseme
  [we see "hello"]

  Now, back in terminal one:
$nano ~/eraseme
  [change "hello" to "goodbye", then ^O to save]

This works, because 'less' is a "browser", not an "editor". I'd be surprised
if 'less' prevented me from changing the file with 'nano'. I don't much care
whether 'nano' writes a new version under a temporary name and swaps the
file names, or unlinks the original, or just overwrites it in place.

> Of course, there is no real
> urgency to do anything at all here, I just thought that it could be nice to
> fix the test suite under Linux too so that I could run it from time to time
> to ensure that both the code and the tests are portable.

Yes, and I think this particular test should be restricted to msw.

>  Just FYI the other failing tests are:
> 
>  * actuarial_table_test, authenticity_test and input_test which all fail
>    to find some files, i.e. I have to install lmi properly and try
>    rerunning them.

Okay, maybe that will resolve itself.

>  * fenv_lmi_test because it relies on MSW-specific x87 FPU behaviour, AFAIR
>    this was supposed to be fixed by my fenv_iec_559 series of patches many
>    years ago.

I have no time for that right now (even though it's certainly more interesting
than what I am working on).

>  * system_command_test which doesn't get the expected error codes: 256 and
>    32512 respectively instead of 1 and 12345.

#else  // defined LMI_MSW

void concrete_system_command(std::string const& command_line)
...
    DWORD exit_code = 12345;
...
    ::GetExitCodeProcess(process_info.hProcess, &exit_code);

Looks like this distinctive return code is used for an unrecognized command,
while a recognized command that fails can give its own return codes. I'm not
sure whether we'd want to change the POSIX alternative, which already seems
to distinguish these two cases. I thought I might get 256 and 32512 in the
following example, but I get 2 and 127:

/home/greg[0]$ls xyzzy
ls: cannot access xyzzy: No such file or directory
/home/greg[2]$xyzzy
zsh: command not found: xyzzy
/home/greg[127]$

but I don't have time to think more about that now. If you know that 256 and
32512 are required by POSIX, then we can test for those platform-specific
values; or we can suppress the distinction for POSIX if it's not defined.

>  All the other tests pass which is really not too bad considering that no
> special effort had been ever made to make them work under Linux AFAIK.

Very good to know. Thanks.