Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
cyberduck opened this issue Jan 17, 2017 · 8 comments
Closed

Comments

@cyberduck
Copy link
Collaborator

3796ed7 created the issue

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

@cyberduck
Copy link
Collaborator Author

3796ed7 commented

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.

@cyberduck
Copy link
Collaborator Author

3796ed7 commented

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.

@cyberduck
Copy link
Collaborator Author

3796ed7 commented

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.

@cyberduck
Copy link
Collaborator Author

3796ed7 commented

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

@cyberduck
Copy link
Collaborator Author

3796ed7 commented

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.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

In 38354.

@cyberduck
Copy link
Collaborator Author

3796ed7 commented

Thanks for fixing this.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Milestone renamed

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants