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

Linux desktop sync client does not preserve execute permissions #3199

Open
iliyasbasir opened this issue May 5, 2015 · 29 comments
Open

Linux desktop sync client does not preserve execute permissions #3199

iliyasbasir opened this issue May 5, 2015 · 29 comments

Comments

@iliyasbasir
Copy link

@iliyasbasir iliyasbasir commented May 5, 2015

Expected behavior

File permission should stay same as own cloud server

Actual Behavior

When Desktop client sync folder from oC; Permission changed for all file inside folder but folder permission stay remain as oC server.

Step to reproduce

  1. created folder at oC(webconsole)
  2. sync via client
  3. look folder at PC where desktop client sync
  4. all files permission is changed inside the folder

Server

Operating system: Ubuntu 13.10
Web server: Apache/2.4.6 (Ubuntu) Server
Database: MySQL server version 5.6.19
PHP version: PHP 5.5.3-1ubuntu2.6 (cli) (built: Jul 7 2014 16:54:32)
ownCloud version: 7.0.5
Storage backend: local
Client configuration - Can you clarify/elaborate what you mean here?
Client version: version 1.8.0
Operating system: Any Linux system (in this case, we'll use Ubuntu 14.04)
OS language: English (US)
Installation path of client: /usr/bin/{redacted}

Logs

s3:Shared/owncloud/support/github-issues/client/3188


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@craigpg

This comment has been minimized.

Copy link

@craigpg craigpg commented May 7, 2015

@dragotin, adding to milestone as it's currently in the top-10.

@ckamm

This comment has been minimized.

Copy link
Member

@ckamm ckamm commented May 8, 2015

I doubt this is in scope for 1.8.2. Supporting file permissions would need updates to client and server and is more like a new feature than a bugfix. It would also need to make sure to work nicely with the different permissions systems that our client platforms (and probably storage backends!) employ.

@bboule

This comment has been minimized.

Copy link

@bboule bboule commented May 11, 2015

So guys just so I am clear, the files as they sync down from the OC server I assume that the changing permissions (i.e. it is no longer has exe permissions) this is expected behavior? @iliyasbasir have you tested this in the lab? Assuming that is the case are we saying this is a feature request?

@dragotin

This comment has been minimized.

Copy link
Contributor

@dragotin dragotin commented May 11, 2015

rather than expected behaviour I'd call it a missing feature. As said before, we need a way to

  1. store permissions (and possibly other file meta data, so called xattr on linux) on the server. There is no obvious way yet, @DeepDiver1975
  2. agree on how we handle permissions cross platform, ie. on Windows, there is no executable flag.

That should be scheduled by product management once we have a clear picture of the scope and the functionality.

@bboule

This comment has been minimized.

Copy link

@bboule bboule commented May 11, 2015

Understood and thank you!! We will take the suggested actions with PM!! Thanks for your help!!

@dragotin

This comment has been minimized.

Copy link
Contributor

@dragotin dragotin commented May 11, 2015

@bboule sorry, it was not said before here, but somewhere else we had this topic as well... don't remember where.

@iliyasbasir

This comment has been minimized.

Copy link
Author

@iliyasbasir iliyasbasir commented May 13, 2015

@ckamm @dragotin this my yesterday evening testing step...still No Luck !
Bellow action is taken

  1.  Build Ubuntu desktop
    
  2.  Install 1.8.0 client
    
  3.  Sync
    
  4.  Permission at sync changed [file  (rw-rw-r--) , Folder (drwxrwxr-x)
    
  5.  Same file at oC server as 755
    

Then,

  1.  Build .zip
    
  2.  Sync via desktop client
    
  3.  Extract some where
    
  4.  Permission cannot preserve as oC 
    
@bboule

This comment has been minimized.

Copy link

@bboule bboule commented May 13, 2015

OK guys I have presented the workarounds for this to the customer the workaround is one of the following: 1. Put the software in an archive and inform the user they need to extract to a location other then the OC sync folder. 2. Simply let them download, copy to another location and then add the x flag back. In the meantme @iliyasbasir can you type up the issue in a SF as a feature request?

@dragotin

This comment has been minimized.

Copy link
Contributor

@dragotin dragotin commented May 19, 2015

can this be closed?

@MTRichards

This comment has been minimized.

Copy link

@MTRichards MTRichards commented May 19, 2015

Can I keep it as a feature enhancement? For tracking purposes.

@bboule

This comment has been minimized.

Copy link

@bboule bboule commented May 19, 2015

Indeed I asked Iliyas to convert or open a new feature request I prefer he close the customer issue and open FR but either way

Sent from my iPhone

On May 19, 2015, at 1:01 PM, MTRichards notifications@github.com wrote:

Can I keep it as a feature enhancement? For tracking purposes.


Reply to this email directly or view it on GitHub.

@bboule bboule closed this Jun 9, 2015
@bboule bboule reopened this Jun 9, 2015
@ogoffart

This comment has been minimized.

Copy link
Collaborator

@ogoffart ogoffart commented Jun 30, 2015

There was an issue already before for the same thing: #820

But we need support for storing metadata on the server. There is a server issue: owncloud/core#6983

It would be nice if the server could allow arbitrary metadata that we can use to store things like local permissions

@felixboehm

This comment has been minimized.

Copy link
Contributor

@felixboehm felixboehm commented Nov 11, 2015

@bboule Please update status, can we remove blue?

@thor84no

This comment has been minimized.

Copy link

@thor84no thor84no commented Aug 3, 2016

This is still an issue for me on Ubuntu 16.04 and Owncloud client 2.1.1.

Not only does it not correctly sync the permissions however, it actively removes the executable flag from all of my scripts periodically - seemingly at random. It's got so bad I'm executing a chmod +x /*.sh in my PS1 function since the flag being removed makes all of my git hooks stop executing - completely silently! It's beyond ridiculous.

@moscicki

This comment has been minimized.

Copy link
Contributor

@moscicki moscicki commented Sep 16, 2016

@ogoffart: what about we add this feature to the sync spec and later on owncloud server catches up with the implementation? Permission bit propagation is a problem for us, too.

I propose to simply add a request/response header for PUT/GET:

OC-Permission: X

Other permission bits could be added later on if relevant.

Other metadata stuff could be added later on as a separate header.

If you are worried that an extra header in PUT request could break the current owncloud server versions, then we could enable this functionality based on capability call, so any existing owncloud server would not be affected at all.

Ref. owncloud/core#6983

@ogoffart

This comment has been minimized.

Copy link
Collaborator

@ogoffart ogoffart commented Sep 16, 2016

that could be done. But I think it is better to have a generic metadata mechanism than adding custom headers like that.

@moscicki

This comment has been minimized.

Copy link
Contributor

@moscicki moscicki commented Sep 16, 2016

Do you have in mind some specific scheme to handle this?

@michaelstingl

This comment has been minimized.

Copy link
Collaborator

@michaelstingl michaelstingl commented Sep 16, 2016

@dragotin Is this something that could find it's way in the 2.3.0 or 2.4.0 release? /cc @felixboehm @pmaier1

00006160

@michaelstingl

This comment has been minimized.

Copy link
Collaborator

@michaelstingl michaelstingl commented Nov 8, 2016

that could be done

When? What are the next steps?

@pmaier1

This comment has been minimized.

Copy link

@pmaier1 pmaier1 commented Nov 9, 2016

Probably we should work on a general "file metadata storage" concept to store all such information including permissions and data like tags or comments as well?! What do you think?

@michaelstingl

This comment has been minimized.

Copy link
Collaborator

@michaelstingl michaelstingl commented Nov 9, 2016

@pmaier1 "file metadata storage" is about where to store this on the server side. But @moscicki asks about the scheme how to let the clients communicate this with the server. As soon this is defined, client implementation could start to begin, independent from server implementation.

@ogoffart

This comment has been minimized.

Copy link
Collaborator

@ogoffart ogoffart commented Nov 14, 2016

@michaelstingl First we need metadata storage on the server and a way for clients to query it. Ideally it should be exposed as a webdav property. And it could be set with a header OC-METADATA-XXX in the PUT (a simple PROPPATCH would work too, but might be a bit slow if every file need to set a metadata.)

@moscicki

This comment has been minimized.

Copy link
Contributor

@moscicki moscicki commented Nov 14, 2016

This requires more comprehensive treatment. I started a protocol discussion here:
https://github.com/cernbox/smashbox/blob/master/protocol/metadata.md

Please contribute.

@michaelstingl

This comment has been minimized.

Copy link
Collaborator

@michaelstingl michaelstingl commented Nov 14, 2016

First we need metadata storage on the server and a way for clients to query it.

No, we don't need to implement this on the server first. We only have to specify the protocol. Then we can start implementing it for the client.

@ogoffart

This comment has been minimized.

Copy link
Collaborator

@ogoffart ogoffart commented Nov 16, 2016

@moscicki From your proposal, We don't need the GET change.

The current owncloud server already has custom webdav property. I don't know however if it will scale to ask for some custom property in every PROPFIND.
But what's missing is being able to change the metadata from the PUT call because we don't want to do a PROPPATCH for every file as that would kill performance.

@moscicki

This comment has been minimized.

Copy link
Contributor

@moscicki moscicki commented Nov 16, 2016

What if I chmod locally the file? Don't you need the PROPPATCH to propagate
just the metadata change?

I think if we draft the spec as I proposed earlier then it will be easier
to get the complete picture and make sure that there are no missing bits.

On Wed, Nov 16, 2016 at 11:42 AM, Olivier Goffart notifications@github.com
wrote:

@moscicki https://github.com/moscicki From your proposal, We don't need
the GET change.

The current owncloud server already has custom webdav property. I don't
know however if it will scale to ask for some custom property in every
PROPFIND.
But what's missing is being able to change the metadata from the PUT call
because we don't want to do a PROPPATCH for every file as that would kill
performance.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3199 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAl9jUAR7KQnK2ly4oYG53cWBl5tdbBAks5q-t4VgaJpZM4EQT_W
.


Best regards,
Kuba

@felixboehm

This comment has been minimized.

Copy link
Contributor

@felixboehm felixboehm commented Dec 20, 2016

@ogoffart Next steps? Should we talk to get an agreement?

@ogoffart

This comment has been minimized.

Copy link
Collaborator

@ogoffart ogoffart commented Jan 11, 2017

The next step is:

  • Make it possible, using custom HTTP tag, to set any custom property metadata with the PUT calls.
    eg: OC-METADATA-UPERM: 0755

  • Make sure that we can query custom property in every PROPFIND without causing massive CPU usage on the server. ( @PVince81 told me that he think the current server implementation might not scale)

  • Also does a change in the custom property invalidate the parent directories etag?

@ogoffart

This comment has been minimized.

Copy link
Collaborator

@ogoffart ogoffart commented Apr 28, 2017

Removing from client milestone because it depends on server feature which are not scheduled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.