cocoaforge

I think I'm seeing a bug with Cyberduck, but I'm not sure if I'm doing something wrong, either.

We manage a bunch of sites in Subversion, but for the ones we don't we use group-writable files, we make them mode 664, and have new files be created with that umask as the directories are all mode 2775 (this is on Linux).

Editing files in this way at the shell works fine, however using Cyberduck in combination with an editor in the automatic download & upload method has some quirks. It seems that the changes are uploaded on save, but Cyberduck pops a warning saying permission is denied anyway. We have the options to change permissions on upload and download both unchecked. I'm also getting reports that sometimes the file is lost or the changes are not in fact saved.

Any advice or pointers are welcome!

No response to this as of yet... is this the proper way to file a bug report?

Is this always reproducable or not? If not, then please file a bug report to bugs@cyberduck.ch. Otherwise make sure you have the permission to create new files in that particular directory.

Uncheck both the "Change permissions on upload" and "Preserve modification date on upload" in Cyberduck > Preferences > Transfers as a workaround.

i think it wasn't fixed? was it? umask is set to 0022 but cyberduck set them always to 0000 on upload. folders created by cyberduck works with the right permissions.

options change permissions on upload and preserve mod date are unchecked… didn't helped. :-(

any idea or better, any solution?

thanks in advance

This is the same issue I reported back in June 2005.

http://forums.cocoaforge.com/viewtopic.php?t=3451

If you leave "change permissions on upload" unchecked, then overwriting an existing file leaves its permissions intact, correctly; but creating a new file via Cyberduck then sets its permissions to 000 which is not a reasonable default. Cyberduck should be honoring the UMASK (or, at a minimum, at least picking a better default value).

The problem with telling Cyberduck to "change permissions on upload" is it alters settings on existing files as well, which is not desirable in a multi-user environment. In a multi-user environment that has any sort of security policy, there is no workable "one size fits all" default permission setting.

This problem still exists in 2.7 (just tested it).

I think one way to resolve this would be to add a checkbox to the upload settings - "Only change permissions when creating new files".

The changelog of 2.7 mentions
- [Bugfix] Honor the existing permissions when replacing files [#--]


This means, that when replacing files, as of 2.7, the same permission mask is applied to the file as the one replaced had.

When creating new files, no CHMOD command is sent, and the file has the default permission set by the FTP server.