`error: file not found` from `tinymist preview` when saving file

[jmdevin]

Description

(See related typst bug typst/typst#3312) When saving a file with vim with :set backupcopy=auto, the tinymist preview process reports this:

error: file not found (searched at /home/john/zotes/resume.typ)

Package/Software version:

tinymist
Build Timestamp:     2024-08-26T16:22:10.986712173Z
Build Git Describe:  v0.11.20
Commit SHA:          1f9a42c2e863f6b1fe8624da796e47adf44a9a83
Commit Date:         None
Commit Branch:       None
Cargo Target Triple: x86_64-unknown-linux-gnu
Typst Version:       0.11.1

Vim: 9.1.689

Logs

[2024-08-30T01:59:51Z DEBUG typst_preview::actor::render] RenderActor: waiting for message
error: file not found (searched at /home/john/zotes/resume.typ)
 = hint: at file /resume.typ

[2024-08-30T02:00:05Z INFO  tinymist::actor::typ_client] TypstActor: failed to prepare main file: NotFound("/home/john/zotes/resume.typ")
[2024-08-30T02:00:05Z ERROR tinymist::actor::typ_client] TypstActor: failed to convert diagnostics: failed to get source: file not found (searched at /home/john/zotes/resume.typ)
[2024-08-30T02:00:05Z INFO  tinymist::task::cache] CacheEvictTask: evict cache in 9.788µs

tinymist client log: I don't know what you would need from vim for this, but if you let me know I'll get it.

Additional context

From vim, :help backupcopy

                        *'backupcopy'* *'bkc'*
'backupcopy' 'bkc'  string  (Vi default for Unix: "yes", otherwise: "auto")
            global or local to buffer |global-local|
    When writing a file and a backup is made, this option tells how it's
    done.  This is a comma-separated list of words.

    The main values are:
    "yes"   make a copy of the file and overwrite the original one
    "no"    rename the file and write a new one
    "auto"  one of the previous, what works best

    Extra values that can be combined with the ones above are:
    "breaksymlink"  always break symlinks when writing
    "breakhardlink" always break hardlinks when writing

    Making a copy and overwriting the original file:
    - Takes extra time to copy the file.
    + When the file has special attributes, is a (hard/symbolic) link or
      has a resource fork, all this is preserved.
    - When the file is a link the backup will have the name of the link,
      not of the real file.

    Renaming the file and writing a new one:
    + It's fast.
    - Sometimes not all attributes of the file can be copied to the new
      file.
    - When the file is a link the new file will not be a link.

    The "auto" value is the middle way: When Vim sees that renaming the
    file is possible without side effects (the attributes can be passed on
    and the file is not a link) that is used.  When problems are expected,
    a copy will be made.

    The "breaksymlink" and "breakhardlink" values can be used in
    combination with any of "yes", "no" and "auto".  When included, they
    force Vim to always break either symbolic or hard links by doing
    exactly what the "no" option does, renaming the original file to
    become the backup and writing a new file in its place.  This can be
    useful for example in source trees where all the files are symbolic or
    hard links and any changes should stay in the local source tree, not
    be propagated back to the original source.
                            *crontab*
    One situation where "no" and "auto" will cause problems: A program
    that opens a file, invokes Vim to edit that file, and then tests if
    the open file was changed (through the file descriptor) will check the
    backup file instead of the newly created file.  "crontab -e" is an
    example.

    When a copy is made, the original file is truncated and then filled
    with the new text.  This means that protection bits, owner and
    symbolic links of the original file are unmodified.  The backup file,
    however, is a new file, owned by the user who edited the file.  The
    group of the backup is set to the group of the original file.  If this
    fails, the protection bits for the group are made the same as for
    others.

    When the file is renamed, this is the other way around: The backup has
    the same attributes of the original file, and the newly written file
    is owned by the current user.  When the file was a (hard/symbolic)
    link, the new file will not!  That's why the "auto" value doesn't
    rename when the file is a link.  The owner and group of the newly
    written file will be set to the same ones as the original file, but
    the system may refuse to do this.  In that case the "auto" value will
    again not rename the file.

[Myriad-Dreamin]

This is because when you don't :set backupcopy=yes, it sometimes doesn't update file atomically. It is a classical problem of transactional fs update... I guess you'll have to use :set backupcopy=yes for a while, as we may not fix it quickly, as it can easily create new bugs or performance issues.