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.

Sign up for GitHub

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

Jump to bottom

Propagate file permissions between clients #6983

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

Propagate file permissions between clients #6983

monkeyhybrid opened this issue Jan 28, 2014 · 29 comments
Labels
enhancement
Milestone
maybe some day

Comments

@monkeyhybrid
Copy link

monkeyhybrid commented Jan 28, 2014 •
edited by DeepDiver1975
Loading

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
Copy link
Contributor

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

@dragotin
Copy link
Contributor

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
Copy link
Contributor

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 dragotin mentioned this issue Feb 21, 2014
Closed
@moscicki
Copy link

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

@ogoffart ogoffart mentioned this issue Feb 25, 2014
Closed
@ogoffart
Copy link

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
Copy link
Member

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 DeepDiver1975 self-assigned this Apr 3, 2014
@DeepDiver1975 DeepDiver1975 mentioned this issue May 12, 2014
Closed
@PVince81
Copy link
Contributor

PVince81 commented Dec 5, 2014

A second DAV URL ? Hmmm...

@DeepDiver1975 DeepDiver1975 modified the milestone: backlog Mar 21, 2015
@ogoffart ogoffart mentioned this issue Jun 30, 2015
Open
@DeepDiver1975 DeepDiver1975 removed their assignment Dec 7, 2015
@ogoffart ogoffart mentioned this issue May 23, 2016
Closed
@tessus
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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
Copy link

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

@focussing
Copy link

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

@focussing
Copy link

@janackermann why is this closed? No solutions?

@AlexAndBear
Copy link

AlexAndBear commented Sep 21, 2021 •
edited
Loading

@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 AlexAndBear reopened this Sep 21, 2021
@stale stale bot removed the status/STALE label Sep 21, 2021
@github-actions
Copy link

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.

@olifre
Copy link

olifre commented Mar 31, 2022

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

@github-actions
Copy link

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.

@olifre
Copy link

olifre commented Sep 28, 2022

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

@github-actions
Copy link

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.

@olifre
Copy link

olifre commented Mar 30, 2023

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

@focussing
Copy link

Hopefully this item will be picked up...

@github-actions
Copy link

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.

@olifre
Copy link

olifre commented Sep 28, 2023 •
edited
Loading

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

@github-actions GitHub Actions
Copy link

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.

@tessus
Copy link

tessus commented Mar 28, 2024

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

What a freaking joke

@github-actions GitHub Actions
Copy link

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.

@olifre
Copy link

olifre commented Sep 25, 2024

Issue is still relevant...

@iasdeoupxe
Copy link
Contributor

@ghost made some valid points: #6983 (comment)

With OCIS now there legacy PHP ownCloud might not receive any new features, could be possible that they will never pick this up (if it didn't happen for 10 years they probably don't see any priority in this).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
maybe some day
Development

No branches or pull requests