Maven Wagon

This is still occurring in the beta-1 version. Can someone please address this?

You may try the sshext:// protocol that will use an external ssh client preinstalled in your machine and see if that fixes the issue

I ran into this problem today and would like to clarify the cause for it. Maven's SftpWagon tries to set the file permissions after file upload, i.e. it issues a chmod on the file (see your stack trace). However, changing file permissions is only allowed to the file owner. Users having full file access (777) may change the file contents but only the owner may change its permissions.

For the moment, we simple use "scp" as the protocol rather than "sftp". The ScpWagen seems to successfully deploy regardless which user currently owns the file in the repo. Unfortunately, the ScpWagen seems to struggle with file permissions. It does not grant write permission to the group. I'm still invastigating why it does not honor the <filePermissions>664</filePermission> element in the settings.xml. For now, we manully grant write permissions after an initial deploy. Later on, the ScpWagen seems not to change the permissions.

ScpWagon correctly specified the file permission but most OpenSSH servers doesn't seem to respect it. I'm not sure if it's an OpenSSH bug or ScpWagon is using some non-standard way to set permissions.

This issue can be fixed by modifying ScpWagon to run chmod command explicitly, but it will make the deployment time much longer.

Instead, this issue can be worked around by changing the default umask of the user. Please try to add 'umask 002' to your .shrc or .bashrc file.

Thanks for your advice about using "umask", I will try this at the next occasion.

As for the ScpWagon, I recently discovered the related discussion at http://jira.codehaus.org/browse/WAGONSSH-44. If the world of SSH server implementations is indeed so evil that there is no standard/reliable way of setting the file permissions, I would appreciate a configuration setting for the ScpWagon to enforce the (otherwise costly) usage of chmod. After all, a long but successful deploy is still better than a quick but improper deploy.

"umask 002" really works fine. Great thanks!

One final note about the explicit chmod for the ScpWagon: If this gets implemented, chmod must not fail the deployment if the currently executing user is not the file owner. Either chmod is only issued for an initial deployment of the file or it silently fails if executed on behalf of a foreign user. Otherwise, we will run into the problem this issue for SftpWagon is already about.

fixed so the permissions are not set unless you ask them to be in wagon.

However, Maven still passes in default settings - I'll open a new issue to remove that in the future.

I've also added a <overridePermissions /> configuration option, which if left empty will block the Maven defaults.

fixed so the permissions are not set unless you ask them to be in wagon.

Brett, how will this fix the issue? If the permissions are specified and two different people upload the same file, wouldn't it still crash for the later deployment? Admittedly, I am not very familar with Wagon but your commit in r660818 doesn't seem to handle this case so I just wonder.

if the permissions are set on the first deployment such that the second user has permission (which is the case in this report), then not attempting to change the permissions will make deployment succeed, as you said in your comment above. It will simply overwrite the file, retaining the original user and permissions.

I assume a scenario where all developers of the project have the permissions configured in their settings.xml (e.g. because people don't like updating their umask which would affect their entire account and not just Maven deployments). This in turn will make Wagon always try to set permissions, not just on first deployment, wouldn't it? In this case, any deployment by somebody other than the file owner will fail, because the SftpWagon is emitting a chmod on the command channel in line 178. It doesn't matter if the permissions were previously set to 777 or something else granting write permissions to the group, only the file owner is allowed to issue chmod on the files. Hence I would have expected SftpWagon.setFileMode() to guard against an exception of the failed chmod and simply continue deployment. Do I miss something here?

you're right. I think it will succeed if the permission is the same as before, but it makes sense to convert this failure to a warning.

I think it will succeed if the permission is the same as before

No, to my knowledge, it will - by design - always fail if the user executing chmod is not the owner.

but it makes sense to convert this failure to a warning.

Not sure about whether "warning" is really the appropriate log level. I mean in general, warnings indicate conditions that should most probably be fixed. But in this case, there is nothing to fix. The user simply doesn't own the file, that's not bad state. So I believe the warning would be another line of noise from Maven that users will learn to ignore. Hence I suggest to use "debug" level in case chmod failed. If there is something wrong with the permissions, a user will simply notice by failing to update the contents of the actual file being deployed.

you're right again, I misunderstood what you were saying. Thanks. So I'll check for chmod failures in both scp and sftp.

I agree on the error level too, that's consistent with the behaviour for directories.

fixed as specified by Benjamin