@dkocher commented

Duplicate for #10079.

5e88f15 commented

With the latest version (Cyberduck 7.2.5), this bug still occurs. It is uncommon for CyberDuck to get into this state, but I have seen it very many times over the years. I believe I have seen it with editors other than BBEdit (in the past I used Smultron), but I don't have historical data to double-check that.

This is a very clearly described bug. To me it does not look like a duplicate of 10079, which looks like a vague "uploading failed, not repeatable" bug -- I would have no idea how to address that, if I were a developer. But this bug is much more specific and has a clear foothold for debugging: Why would CyberDuck ever say "Prepare thefilename (Trash)"?

My experience matches tempelmann's.

This bug usually hits me when I am using my laptop, moving between various internet connections (at work, at home, at a cafe, etc.), and CyberDuck has to keep re-establishing the FTP connection (I hit save in the editor, the upload fails, the connection goes grey in CyberDuck, it tries again after a few seconds, it establishes a new connection, the upload works -- all automatic, because CyberDuck is so nice!). Sometimes my editing window becomes "stale" in some way I don't understand -- maybe it is wedded to the previous FTP connection somehow. I think of this staleness and this bug as being the same, but I never really looked into it before now. The staleness is clearly identifiable by the messed-up filename (see point 4 below).

It looks like a bug in both CyberDuck and BBEdit. Point 5 below looks like a CyberDuck bug, and point 6 below looks like a BBEdit bug. And it looks like CyberDuck is responsible for things getting into this messed-up state in the first place, but who knows.

More observations:
3. The problem is associated with the file. Other files from the same server in the same BBEdit window continue to work normally. Closing the problematic file in BBEdit and then reopening it by double-clicking it in CyberDuck downloads the file from the server again (CyberDuck produces the alert saying the download was successful) but BBEdit shows the trash file again (which is where your edits were saved), so it looks like everything is normal and you are editing the downloaded file which contains your latest edits, but this is an illusion -- in fact in BBEdit you are just seeing and editing the trash file again, not the downloaded file! The trash file only appears in BBEdit after the download succeeds, so things feel like they are working normally. It is not immediately obvious that in fact nothing is working and all your work that you keep saving is just all going in the trash.
4. The trash file has a name like "enter 00-59-24-222.php" when the actual filename is "enter.php". (Once you know to look for this, this strange filename being displayed by the editor is the main clue that things are messed up.) Maybe this is a clue for where the problem is coming from? If I delete this file from the trash, after closing it in BBEdit, then when I try to reload the file (by double-clicking in CyberDuck), CyberDuck downloads the file successfully (according to the notification it puts up), after which BBEdit says: "This operation couldn't be completed, because an error occurred. File not found (macOS error code: -43)." Other files, even with the same name (different directory), open in BBEdit just fine via CyberDuck, but trying to open the problematic file always leads to this error.
5. If I hunt down the local location of the file, in /private/var/folders/..., then I see that the file is alternately appearing and disappearing. In other words, every time I try to reload the file (after deleting it from the trash) as described in the previous paragraph, (1) CyberDuck appears to succeed while BBEdit gives an error message, and (2) the file either appears or disappears (it alternates) from the directory-mapped structure on the local disk (where I see copies of the server files that I am editing, including their parent directories, all the way up to the top server directory that CyberDuck is accessing via FTP). This certainly makes it look like the bug is not entirely on the BBEdit side of things. If the file has not been deleted from the trash, then BBEdit opens the trash file after the download, but [I would guess] the "real" directory-mapped local file is still disappearing and reappearing.
6. If I drag the local file (after one of the times where it appears instead of disappearing) into BBEdit, then BBEdit still gives exactly the same error, "File not found (macOS error code: -43)." In fact it puts up that alert panel twice, for some reason. This certainly makes it look like the bug is not entirely on the CyberDuck side of things. Quick Look can show me the file contents just fine, and I can even edit the file with TextEdit and when I save, then CyberDuck uploads the file just fine! But even if I drag the file icon from TextEdit to BBEdit, BBEdit complains about "file not found"! This suggests that some kind of meta-data (OS flags or extended attributes or who knows) about the file is messed up. Or maybe meta-data in the parent directory is messed up? Because deleting the file (by dragging to trash) and re-downloading it (creating a new file) does not fix the problem.
7. Restarting CyberDuck did not fix the problem. It continued as before. Then, restarting BBEdit, the problem went away. Saving from BBEdit successfully uploaded the file. So it looks like the messed-up state is somehow maintained by BBEdit. How the messed-up state arises in the first place, I can't say, but I've only seen it happen with files provided by CyberDuck.

If there is other information you need, let me know. This is just an occasional bug, but it does come up every so often, so I could check more things the next time it happens, if there is anything else to check.

@dkocher commented

We have switched our implementation in 4b6e672. Can you please try if still see this issue with the current snapshot build
by updating from within Cyberduck in Preferences → Update →Automatically check for updates in → Snapshot Builds.