core icon indicating copy to clipboard operation
core copied to clipboard

Propagate file permissions between clients

Open monkeyhybrid opened this issue 11 years ago • 29 comments

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!

monkeyhybrid avatar Jan 28 '14 13:01 monkeyhybrid

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

PVince81 avatar Jan 29 '14 08:01 PVince81

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 avatar Jan 29 '14 12:01 dragotin

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.

dragotin avatar Feb 21 '14 09:02 dragotin

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

moscicki avatar Feb 21 '14 14:02 moscicki

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)

ogoffart avatar Feb 25 '14 20:02 ogoffart

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 ....

DeepDiver1975 avatar Apr 03 '14 21:04 DeepDiver1975

A second DAV URL ? Hmmm...

PVince81 avatar Dec 05 '14 17:12 PVince81

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.

tessus avatar May 23 '16 19:05 tessus

If this is something super important to you, feel free to post it in here: https://github.com/owncloud/core/issues/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.

MTRichards avatar May 23 '16 21:05 MTRichards

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 :+1: is not really helping at all :-)

from https://github.com/owncloud/core/issues/4579#issuecomment-66352582

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.

ghost avatar May 24 '16 05:05 ghost

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 ?

AxelRb avatar Apr 19 '17 15:04 AxelRb

See also this comment for what is still needed in the server: https://github.com/owncloud/client/issues/3199#issuecomment-271856596

ogoffart avatar Jun 19 '18 08:06 ogoffart

I am synching 2 macOS systems and same issue overhere. Any idea when this is solved? Or is it a server problem?

focussing avatar Sep 20 '21 09:09 focussing

@JanAckermann why is this closed? No solutions?

focussing avatar Sep 21 '21 08:09 focussing

@focussing We just have recently introduced a new stalebot. You have responded to this ticket 23 hours ago, unfortunately, the stale bot didn't recognize staled items, which were not staled by the bot himself. so this ticket was a victim of a manual bunch close. I reopen it, thy for letting me know!

AlexAndBear avatar Sep 21 '21 08:09 AlexAndBear

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Mar 31 '22 01:03 github-actions[bot]

Since stale bot became active again, pinging this issue — I suffer from this problem at least once a week, and have already migrated some of my use cases to other sync solutions. Sorry for pinging so many subscribed people by this message which does not add to the discussion, but there appears no other way to mark it as "still applies" and "not stale".

olifre avatar Mar 31 '22 08:03 olifre

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Sep 28 '22 01:09 github-actions[bot]

Since stale bot became active again, pinging this issue, it is still relevant.

olifre avatar Sep 28 '22 01:09 olifre

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Mar 30 '23 01:03 github-actions[bot]

Since stale bot became active again, pinging this issue, it is still relevant.

olifre avatar Mar 30 '23 01:03 olifre

Hopefully this item will be picked up...

focussing avatar Mar 30 '23 05:03 focussing

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Sep 28 '23 01:09 github-actions[bot]

Since stale bot became active again, pinging this issue, it is still very relevant.

olifre avatar Sep 28 '23 01:09 olifre

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Mar 28 '24 01:03 github-actions[bot]

Well, after being ignored for 10 years you can probably close it.... ;-)

What a freaking joke

tessus avatar Mar 28 '24 01:03 tessus