"No such file" bug

[kripper]

Do you read the FAQ?

Yes I do..

Describe the bug

When triggering a second file-upload concurrently (e: press CTRL+S twice), the "upload with temp files" feature fails and throws a "No such file" fatal error.

To Reproduce

Press CTRL+S twice to trigger a file uploads task. You will get a "No such file" fatal error (see explanation below).

Expected behavior

The second upload task should not fail. First task could be canceled.

** Screenshot **

** Explanation **

We can celearly see two "moving from" log entries for the same file, so the second fails because the file is not there anymore.

** Solution **

I believe we can just cancel the first upload task when the second task starts (before it starts, at the begining of the code), because the last save operation should always overwrite the first one.

[Natizyskunk]

I personally can't replicate this bug :/

[kripper]

Make sure you have enabled the new added option to use a temp file.

[Natizyskunk]

I'm already using the useTempFile option and i'm also using openSsh option.

[kripper]

Enable the autoupload option and press the save shortcut many times very quickly. Maybe your connection is too fast. If possible, try to connect to a slow/distant remote server. I'm pretty sure this is very reproducible. It happens when you initiate a second upload task while the first one is still running.

[anordin95]

I'm encountering the same issue.

I can re-create the error with the following sftp.json config and repeatedly, rapidly saving a file. The rapidity with which you save the file matters. If done slowly, there will be no error. There may be a lurking issue when it comes to re-creating this bug: the latency to the remote filesystem/server must be greater than the time it takes you to save the file repeatedly locally, otherwise the saves and ensuing invocations of the extension will be serial.

{
    "name": "[scrubbed]",
    "host": "[scrubbed]",
    "remotePath": "[scrubbed]"
    "username": "anordin",
    "protocol": "sftp",
    "port": 22,
    "uploadOnSave": true,
    "useTempFile": true,
}

I was able to workaround the bug by removing "useTempFile": true,.