Cyberduck Mountain Duck CLI

#10719 closed defect (worksforme)

Editing with BBEdit sometimes opens file from Trash, then losing any further changes

Reported by: tempelmann Owned by: dkocher
Priority: normal Milestone: 7.3.0
Component: core Version: 6.9.4
Severity: major Keywords: edit trash
Cc: Architecture: Intel


Using BBEdit (12.6.4) as the designated Editor, I often edit text files from a sftp server on my Mac, and then close the text window in BBEdit again. Later, I double click the same file in Cyberduck's sftp browser so it opens again in BBedit. This generally works.

However, after a while, it happens that BBEdit opens the file not from the tmp directory but from a file in the Trash (which Cyberduck apparently moved there, or so I gather from other tickets related to "edit trash"). When this happens, saving my changes in BBEdit does not lead to updating them on the server any more. I don't even get any kind of error message, which sometimes caused me some lost work (hence it should be considered a rather severe bug) when I did not notice this.

Two observations:

  1. When I double click a file in CD to edit, it ALWAYS shows "Prepare thefilename (Trash)" in the window's bottom text field, even if the file ends up being opened on the local tmp folder, not in the Trash. In wonder what's up with that?
  2. Once this gets stuck with the Trashed file being opened by BBEdit, I need to empty my trash and also restart BBEdit to make it work again.

So, is this a bug in CD or in BBEdit?

This has been bugging quite a while now, i.e. it also happens in version 5. Several years ago, though, this did not happen. Not sure what changed.

Unfortunately, I have no idea how to reproduce it at will. That's why I haven't reported it for so long.

Please have at least a check about why "(Trash)" appears in the status during download. Maybe that's part of the cause of this?

I have no log files to attach because system.log shows nothing about it when I search for "cyberduck", and it's not a ftp protocol issue (and only those appear in the log drawer, it seems to me).

Change History (6)

comment:1 Changed on May 31, 2019 at 11:54:06 AM by tempelmann

  • Summary changed from Editing with BBEdit sometimes opens file from Trash to Editing with BBEdit sometimes opens file from Trash, then losing any further changes

comment:2 Changed on May 31, 2019 at 11:58:07 AM by dkocher

  • Milestone set to 7.0
  • Owner set to dkocher
  • Status changed from new to assigned

comment:3 Changed on May 31, 2019 at 1:53:40 PM by dkocher

  • Resolution set to duplicate
  • Status changed from assigned to closed

Duplicate for #10079.

comment:4 Changed on Feb 20, 2020 at 2:17:09 PM by matthew

  • Resolution duplicate deleted
  • Status changed from closed to reopened

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

comment:5 Changed on Mar 13, 2020 at 4:01:35 PM by dkocher

  • Milestone changed from 7.0 to 8.0

We have switched our implementation in r48637. 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.

comment:6 Changed on Apr 13, 2020 at 8:06:34 AM by dkocher

  • Milestone changed from 8.0 to 7.3.0
  • Resolution set to worksforme
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.