Cyberduck Mountain Duck CLI

#9727 closed defect (worksforme)

Remote File-Path Obfuscated in Text Editor

Reported by: moghilemear Owned by:
Priority: normal Milestone:
Component: core Version: 5.1
Severity: normal Keywords: Editor filepath too long for display
Cc: Architecture: Intel
Platform:

Description (last modified by moghilemear)

Issue: file path displayed by text editor is obfuscated Cyberduck 5.1.3, OSX 10.12, TextWrangler 5.5.2, Remote: Linux CentOS 7

Class: it is not clear whether this is a feature, enhancement, or defect class of issue. Also, this is associated with a collaboration between Cyberduck & Textwrangler/BBedit apps.

TextWrangler is a standard text editor for OSX, and is configured as my Cyberduck editor. When editing a remote file (selected via Cyberduck interface), TextWrangler displays the the *local - temporary* filepath, (not the remote filepath).

This may or may not be the intended design of Cyberduck (i.e. show the local filepath) the problem is that the local tmp path is extremely long and therefore useless when attempting to identify the originating location (i.e. remote dir path) of the file.

I reported this to TextWrangler. Upon investigation of the matter the tech team directed me to report this to Cyberduck as well (citing that it is a collaboration issue).

TextWrangler provided me with a more technical description: "BBEdit and TextWrangler rely on CyberDuck passing certain information in the 'odoc' event, indicating the file's origin. It looks as though when CyberDuck changed over to use file monitoring to detect when the file is saved, it stopped doing this, so that BBEdit and TextWrangler have no way to know where the file came from (and thus no information available to display the remote path)."

If this is not a defect, then I would like to request that there be a Cyberduck Config parameter, to allow the user to control whether the local or remote file-path is displayed.

Here is an example of just the tmp dir part of the displayed filepath "/private/var/folders/gh/9zlxkcdd68b6kgrtw85nx4s80000gn/T/daeac1d1-cb66-43d1-b4aa-33258716b313/<remote filepath goes here>"

Change History (9)

comment:1 Changed on Oct 6, 2016 at 4:30:14 PM by moghilemear

  • Summary changed from File Path displayed by text editor to Remote File-Path Obfuscated in Text Editor

comment:2 Changed on Oct 6, 2016 at 4:33:19 PM by moghilemear

  • Type changed from feature to defect

comment:3 Changed on Oct 6, 2016 at 4:39:03 PM by moghilemear

  • Description modified (diff)

comment:4 Changed on Oct 6, 2016 at 4:39:56 PM by moghilemear

  • Description modified (diff)

comment:5 Changed on Oct 6, 2016 at 4:40:08 PM by moghilemear

  • Description modified (diff)

comment:6 Changed on Oct 6, 2016 at 4:40:44 PM by moghilemear

  • Description modified (diff)

comment:7 Changed on Oct 6, 2016 at 4:41:40 PM by moghilemear

  • Description modified (diff)

comment:8 Changed on Oct 11, 2016 at 2:42:24 PM by dkocher

  • Resolution set to worksforme
  • Status changed from new to closed

Thanks for your bug report. We no longer support editing with AppleScript ODB protocol because this is no longer possible for sandboxed applications. Therefore this feature cannot be supported. However the local directory structure created for the temporary local file will match the path on the server.

comment:9 Changed on Oct 12, 2016 at 11:46:09 AM by dkocher

As far as I am aware , there isn't anything in the ODB suite which prevents sandboxed applications from adding the appropriate parameters (described above) when sending the 'odoc' event. Or, put another way, since you're already able to send the 'odoc' event to BBEdit, adding the keyFileSender and keyFileCustomPath data will not break the rules. Note that if for some reason you need a sandboxing entitlement for sending Apple Events to other applications, this may readily be done with a "temporary" exception (quoted because the exception has been in place for about four years and counting ):

     <key>com.apple.security.temporary-exception.apple-events</key>
     <array>
         <string>com.barebones.bbedit</string>
         <string>com.barebones.textwrangler</string>
         // add the bundle IDs of other ODB-compatible applications
     </array>

This list is finite, and need only include applications that you know support the ODB suite (BBEdit and TextWrangler among them, but of course there may be others).

Note: See TracTickets for help on using tickets.