Linux desktop sync client does not preserve execute permissions

[iliyasbasir]

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]

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

[ckamm]

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]

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]

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]

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

[dragotin]

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

[iliyasbasir]

@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]

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]

can this be closed?

[MTRichards]

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

[bboule]

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 [email protected] wrote:

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

—
Reply to this email directly or view it on GitHub.

[ogoffart]

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]

@bboule Please update status, can we remove blue?

[moscicki]

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 [email protected]
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]

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

[ogoffart]

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]

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

[RobertoFranceschini]

This is a key feature, missing this makes the synced data just not usable at all for my purposes.

[tgwaste]

Does this have a chance of ever happening? This is the one thing that keeps OwnCloud from being a Dropbox killer. They had this on day #1 :(

[michaelstingl]

Does this have a chance of ever happening?

Realistically not in 2021, sorry.

[moscicki]

Hello guys at owncloud, 6 years and counting.... no pressure ;-)

[tgwaste]

Hello guys at owncloud, 6 years and counting.... no pressure ;-)

amen. is this really such a big thing that it couldn't be solved in 6 years?

[michaelstingl]

Hello guys at owncloud, 6 years and counting.... no pressure ;-)

@moscicki Idea was, your team makes a proposal for the CS3 API's.

[gmacmaster]

Is there an estimate as two when this might get fixed?

[focussing]

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