Core: Wrong folder date when syncing

[solopa]

First, I'm not sure if this is a core problem or a client (Windows) problem. I put it here since it's the same problem as issue #1897 (closed because it needed info).

Expected behaviour

The creation date of a folder should be the same in every computer after syncing.

Actual behaviour

After syncing, the date of a folder is different in each computer.

Steps to reproduce

1. Create a new folder in a computer (let's say at 9:00). Sync ownCloud.
2. Later, in another computer, sync ownCloud. It will create the folder of step 1 but it won't set its creation date to be the same as that folder. I'd expect it to be 9:00, but it will have the current time.
   

   Server configuration

Raspberry Pi running ownCloud with "version":"6.0.0.16" and "versionstring":"6.0.1".
Database: SQlite.
PHP version: 5.4.4
Updated from an older ownCloud or fresh install: fresh install

Client configuration

One computer: Windows 7 64 bits
Another one: Windows XP 32 bits (problem happens with both of them).
Client: ownCloud for Windows (obviously :)) v.1.5.0 (build 1913).

Hope you can have a look at this, at least to see if it's reproduceable. Thanks for your time!

[PVince81]

Yes, I just observed the issue with the Linux client 1.5.1 as well.
It seems that only the file's timestamps are updated to match the ones from the server but not the ones of folders.

Bug or by design @dragotin ?

[ogoffart]

We don't update anymore the timestamp of the directories, because it tends to change all the times we are adding or removing files anyway.

[shadone]

ogoffart: the _creation_ date of the folder shouldn't change if you add or removes files though. This sounds like a valid bug to me. Also Dropbox does this :)

[karlitschek]

@ogoffart What is the status here?

[ogoffart]

csync never touched the creation date (of files or folder). The creation date is not even part of the property exposed by webdav.
For files, the modification time is kept in sync.
csync used to sync the modification time of directory as well. But it was not so accurate because the modification date for folders is always changing.

For example, if one modifies a file on the server, it needs to be downloaded, but then a temporary files is created which change the modification time of the directory. Next sync we would then have to sync the modification date again. And that sounds wrong.

So because it was unreliable anyway, we stopped syncing the modification time of directories, saving time and bandwidth.

If having the modtime of the directory synced is soo important, we could add this feature back.

[PVince81]

So should we close this as "expected behavior" ?

[PVince81]

Ok I just read the attached https://github.com/owncloud/mirall/issues/1566 and this seems to be an issue.

[enoch85]

I’m closing this issue because it has been inactive for a few months. This probably means that the issue is not reproducible or it has been fixed in a newer version.

Please reopen if you still encounter this issue with the latest stable version and then please use the issue template. You can also contribute directly by providing a patch – see the developer manual. :)

Thank you!

[Morganlej]

Well it is still valid, but probably enough to have #14008 , #1566 open.
So this is intended, by design, and no plans to change?
As it is against users expectation and normal syncing behaviour, it should be clearly noted in user documentation. (maybe it is, have not read it for a while)

[PVince81]

It is by design.

We can keep the server ticket as enhancement request though.

[Morganlej]

I agree behaviour should be kept as is.
Valid reasons are listed above.
However it should be a FAQ somewhere, and in manual (i do not know the status there)

[PVince81]

@carlaschroder is there any doc about the fact that folder mtimes are not synced ?

[carlaschroder]

@PVince81 There is not. Yet.

[toddpfaff]

This problem still exists in owncloud-8.2.1.

This is a show-stopping problem for some of our owncloud users. We may have to look at other solutions if this behaviour isn't changed in owncloud. Since we also have a seafile deployment I'll be testing for this problem on that platform. I'd hate to have to move our users from owncloud to seafile because of this one problem that seems like it should be quite trivial to solve, but that may be the result.

I understand the "by design" arguments above, but if possible I'd like to see this as a configurable option, if not always on. That is, for people who want to save sync time and bandwidth, they can disable directory mod time syncing. For all others, directory time mod syncing is on by default.

[toddpfaff]

I'm following up on what I said in my previous post about testing for this problem in seafile. I've tested for this directory modification time issue in owncloud-8.2.2, seafile-5.0.4, and dropbox. It seems that at this time seafile is the only one of the three that properly preserves directory modification times.
seafile had a similar problem back in 2013 but they have since changed the behaviour:
https://groups.google.com/forum/#!topic/seafile/D0CwrDH5PBU

[herrep]

What about synchronizing the creation and modification date of directories only upon an initial sync, i.e. when creating the directory on the client for the first time? https://github.com/owncloud/client/issues/7119