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

Propagate file permissions between clients #6983

Open
monkeyhybrid opened this issue Jan 28, 2014 · 12 comments
Open

Propagate file permissions between clients #6983

monkeyhybrid opened this issue Jan 28, 2014 · 12 comments

Comments

@monkeyhybrid
Copy link

@monkeyhybrid monkeyhybrid commented Jan 28, 2014

I work with a lot of executable files, mostly shell scripts, that get modified or added to each day. I would like to use Owncloud to sync these files across clients but it does not propagate the executable permissions which means I have to manually 'chmod +x' various files when I move between clients.

I'd love to see this capability added to Owncloud!

@PVince81

This comment has been minimized.

Copy link
Member

@PVince81 PVince81 commented Jan 29, 2014

I think in general it doesn't propagate permissions at all at the moment.
@dragotin

@dragotin

This comment has been minimized.

Copy link
Contributor

@dragotin dragotin commented Jan 29, 2014

No, it does not yet. We need support on server side to store extra meta information as WebDAV does not support permissions by default.

@dragotin

This comment has been minimized.

Copy link
Contributor

@dragotin dragotin commented Feb 21, 2014

Let me hijack this report to track the general feature request of transmitting permissions of directories and files from the server to the clients. @DeepDiver1975 we talked about that.

@moscicki

This comment has been minimized.

Copy link

@moscicki moscicki commented Feb 21, 2014

I would also like to see this feature... do you maybe know when it could become available?

@ogoffart

This comment has been minimized.

Copy link

@ogoffart ogoffart commented Feb 25, 2014

I think it should be fine if the server would allow to store abitrary (opaque) meta-data. Then the client can interpret metadata end changes the +x flag accordingly on the client. This does not have anything to do with Shared directory and the server do not need to interpret those metadata. (but it can to visualize or edit them)

@DeepDiver1975

This comment has been minimized.

Copy link
Member

@DeepDiver1975 DeepDiver1975 commented Apr 3, 2014

I will prepare a pull request these days to show how this enhanced web dav interface will look like and work. From my current understanding we need a second dav url to properly reflect the necessary requirement ....

@PVince81

This comment has been minimized.

Copy link
Member

@PVince81 PVince81 commented Dec 5, 2014

A second DAV URL ? Hmmm...

@tessus

This comment has been minimized.

Copy link

@tessus tessus commented May 23, 2016

My 2 cents (added to the ticket that has just been closed):

This ticket has been open for 2 and a half years!

Unless you move it out of the backlog stage, it will NEVER be implemented. Maybe the developers will understand, if a lot of tickets are open regarding this topic, that it might be rather important for people.

So what's happening here is the following: All related tickets are and will be closed, because they are a duplicate. This (the original) ticket on the other hand is and will be ignored. But maybe I'm wrong. I will check back in another 2 years.

@MTRichards

This comment has been minimized.

Copy link
Contributor

@MTRichards MTRichards commented May 23, 2016

If this is something super important to you, feel free to post it in here:
#24684

It does not guarantee that it gets done, but it does keep it from getting lost and gives it the light of folks considering and voting on this feature request.

@ghost

This comment has been minimized.

Copy link

@ghost ghost commented May 24, 2016

Plus the following is probably also matching here:

But since we're really a very friendly and open-minded open-source project everybody can contribute and if you really "need" this feature for your usage in Enterprise environments there are some choices to get this done:

  • Implement the things yourself
  • Find a software developer implementing this for you
  • Throw money at it: bountysource.com/teams/owncloud
  • Get an Enterprise Subscription from ownCloud Inc., the company employing most of the core developers, and pay enough to get this on the roadmap.

I don't want to be impolite here or say that this feature is unimportant, I just want to say that we're aware of this feature request and might consider it at the future. But writing 👍 is not really helping at all :-)

from #4579 (comment)

Maybe the developers will understand, if a lot of tickets are open regarding this topic, that it might be rather important for people.

In general a lot of open tickets about the very same won't help getting things faster and is just filling up the issue tracker.

@AxelRb

This comment has been minimized.

Copy link
Contributor

@AxelRb AxelRb commented Apr 19, 2017

It would be nice if the permissions were propagated correctly between (Unix) clients.
I noticed there is some basis for that to happen, namely the permissions field in the oc_filecache table.
I have an old entry (from an older OC version) for at least one file which lists the permissions with 17 and syncs the file on a new client with only read permissions (444).
At least in the csync_update.c there seems to be a permission check.
Anyone knows whether this feature was removed at some point ?

@ogoffart

This comment has been minimized.

Copy link

@ogoffart ogoffart commented Jun 19, 2018

See also this comment for what is still needed in the server:
owncloud/client#3199 (comment)

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