Cyberduck Mountain Duck CLI

#9813 closed defect (fixed)

Edit command changes permission of file, even if only reading the file

Reported by: tempelmann Owned by: dkocher
Priority: high Milestone: 5.4
Component: core Version: 5.2.2
Severity: normal Keywords:
Cc: Architecture:
Platform:

Description (last modified by tempelmann)

I have the following dir:

drwxr-xr-x 2 edit www   4096 Jan 17 18:05 ./
drwxr-xr-x 4 edit www   4096 Jan 16 00:42 ../
-rw-rw-r-- 1 edit www  57569 Jan 17 18:09 news.log

Now, if I double click "news.log" in Cyberduck to view the file, its permissions immediately change to:

-rw-r--r-- 1 edit www  56894 Jan 17 18:09 news.log

I.e, it removes the groups write access. This is a severe bug, IMO. The permissions should not be changed for an existing file, ever, especially not if I only read it, not modify it.

If I do the same with Cyberduck 4.7.2, the permissions remain unchanged, as expected. That should prove it's not a problem with my setup but with Cyberduck.

Both versions have the same prefs, including the option "change permissions" for downloads (644). But that should only affect the file downloaded to my computer, not the file on the server, right?

Access is via SFTP, if that matters.

I've attached the prefs file, cleaned up a little (removing the NS..., bookmarks and session entries)

Attachments (2)

cyberduck-prefs.plist (6.0 KB) - added by tempelmann on Jan 17, 2017 at 5:19:42 PM.
prefs file
Screen Shot 2017-01-17 at 19.11.47.png (37.4 KB) - added by tempelmann on Jan 17, 2017 at 6:14:29 PM.
Transfer permissions settings

Download all attachments as: .zip

Change History (14)

Changed on Jan 17, 2017 at 5:19:42 PM by tempelmann

prefs file

comment:1 Changed on Jan 17, 2017 at 5:20:55 PM by tempelmann

  • Description modified (diff)

comment:2 Changed on Jan 17, 2017 at 5:21:15 PM by tempelmann

  • Description modified (diff)

comment:3 Changed on Jan 17, 2017 at 5:23:29 PM by tempelmann

  • Description modified (diff)

comment:4 Changed on Jan 17, 2017 at 5:24:52 PM by tempelmann

Oh, now that I've restarted both apps, I cannot reproduce it any more. But it happened to me more than once before (i.e. the file's permissions on the server changed), but I only figured out now that it's Cyberduck's Edit cmd that caused it. Maybe the re-running and testing with version 4.x "fixed" it? Not sure. Still, this is worrying.

comment:5 Changed on Jan 17, 2017 at 5:28:30 PM by tempelmann

Ah, here we go:

It goes like this:

  1. group write is permitted on the server's file.
  2. I download the file with Cyberduck's Edit cmd. -> permissions remain intact.
  3. I change the file on the server, giving it a new mod date.
  4. I download the file again with the Edit cmd -> permissions GET CHANGED.

I hope you can reproduce this.

comment:6 Changed on Jan 17, 2017 at 5:36:47 PM by tempelmann

Oddly, during testing, (the assigned Editor is BBEdit 10), I suddenly also often get a "Connection Failed. Failed to open application BBEdit for news.log." error, especially after just changing the server's file date using the "touch" cmd on the server. "Try Again" then fetches it, and the permissions remain intact. This is all very wonky. I find no such issues with version 4 of Cyberduck.

BTW, are you still the same developer as the one for version 3? I paid back then, but wouldn't mind paying again.

Last edited on Jan 17, 2017 at 5:38:47 PM by tempelmann (previous) (diff)

comment:7 Changed on Jan 17, 2017 at 6:10:41 PM by tempelmann

And here is the transcript (it would be helpful if it included timestamps). It includes the results from using the Edit button two times. The second time, the permissions got updated, as you can see. Even worse, it appears that Cyberduck uploaded a new file, so it seems that Cyberduck believed that the previously downloaded file was edited and probably uploaded that, even though I never changed the downloaded file.

But even if it just uploaded the new file - it should not have changed the original server file's permissions. The permission of the local downloaded file are not supposed to match those on the server. The server has its own user after all, and also has its own permissions setup, which do not match those on the local machine. At least not without a warning.

The global Cyberduck prefs that let me specify Upload permissions cannot help me here as I would have to change those prefs every time I upload some file. So, instead, I expect Cyberduck to keep the original file permissions on the server instead of using some global setting (and note that I have not enabled to set the permissions for Upload, which means I intend to keep the original permissions).

So, in all, these are actually two separate issues.

I'm going back to version 4 for now.

5 OPENDIR
6 READDIR
7 READDIR
8 CLOSE
9 OPEN
10 READ
11 READ
12 READ
13 READ
14 READ
15 READ
16 CLOSE
17 OPENDIR
18 READDIR
19 READDIR
20 CLOSE
21 OPEN
22 READ
23 READ
24 READ
25 READ
26 READ
27 READ
28 CLOSE
29 OPENDIR
30 READDIR
31 READDIR
32 CLOSE
33 OPEN
34 WRITE
35 WRITE
36 WRITE
37 CLOSE
38 REMOVE
39 RENAME

Changed on Jan 17, 2017 at 6:14:29 PM by tempelmann

Transfer permissions settings

comment:8 Changed on Jan 17, 2017 at 6:14:41 PM by tempelmann

In fact, the setup of my Prefs is a clear indication that I do NOT want the permissions messed with at all on the server side. See the second attachment for that, showing my Prefs.

It says to preserve the permissions from the server on Download, i.e. if I had "write group" permissions on the server, the downloaded file should as well, at best. And I said not to change the permission on uploaded. How can Cyberduck turn this into disabling "write group" permissions is beyond me.

Huh, I have a suspicion: The fact that the permissions get reset from 664 to 644 is a behavior of my server. The transcript shows that Cyberduck did not attempt to change the prefs, meaning that it leaves it up to the server. So, to get what I want, I'd have to change the Cyberduck prefs to also set the Permissions on Upload. That way, the permissions get copied to the downloaded local file, and set again with the upload of the local file to the server.

However, I just tested this theory and found that that's not worked that way, either. When I do that, I can see that the local file has indeed 664, but when I modify and save it, so that Cyberduck automatically re-uploads it, then it doesn't even issue the SITE CHMOD command and so the server resets permissions to 644. Oddly, though, I've seen a SITE CHMOD 644 earlier in the transcript. So, there's some problem there, too. I'll have to stop looking into this now, but if I get back to it tomorrow, I'll open a new ticket for this separate issue, with more details when it happens and when not.

For now, please focus on the bug that causes a unwanted re-upload when I re-download (using Edit) a file that got updated on the server.

Last edited on Jan 17, 2017 at 6:35:53 PM by tempelmann (previous) (diff)

comment:9 Changed on Feb 1, 2017 at 9:45:37 AM by dkocher

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

comment:10 Changed on Mar 6, 2017 at 10:17:13 AM by dkocher

  • Milestone changed from 6.0 to 5.3.10
  • Resolution set to fixed
  • Status changed from assigned to closed

In r38354.

comment:11 Changed on Mar 6, 2017 at 10:21:16 AM by tempelmann

Thanks for fixing this.

comment:12 Changed on Mar 8, 2017 at 9:53:50 AM by dkocher

  • Milestone changed from 5.3.10 to 5.4

Milestone renamed

Note: See TracTickets for help on using tickets.
swiss made software