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

Wrong folder date when syncing #7009

Closed
solopa opened this Issue Jan 30, 2014 · 15 comments

Comments

Projects
None yet
9 participants
@solopa

solopa commented Jan 30, 2014

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

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 Feb 17, 2014

Member

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 ?

Member

PVince81 commented Feb 17, 2014

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

This comment has been minimized.

Show comment
Hide comment
@ogoffart

ogoffart Feb 17, 2014

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.

ogoffart commented Feb 17, 2014

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

This comment has been minimized.

Show comment
Hide comment
@shadone

shadone Feb 17, 2014

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 :)

shadone commented Feb 17, 2014

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 karlitschek added Bug and removed Bug labels Feb 25, 2014

@karlitschek

This comment has been minimized.

Show comment
Hide comment
@karlitschek

karlitschek Mar 4, 2014

Member

@ogoffart What is the status here?

Member

karlitschek commented Mar 4, 2014

@ogoffart What is the status here?

@ogoffart

This comment has been minimized.

Show comment
Hide comment
@ogoffart

ogoffart Mar 4, 2014

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.

ogoffart commented Mar 4, 2014

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

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 May 6, 2014

Member

So should we close this as "expected behavior" ?

Member

PVince81 commented May 6, 2014

So should we close this as "expected behavior" ?

@PVince81

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 May 6, 2014

Member

Ok I just read the attached owncloud/client#1566 and this seems to be an issue.

Member

PVince81 commented May 6, 2014

Ok I just read the attached owncloud/client#1566 and this seems to be an issue.

@enoch85

This comment has been minimized.

Show comment
Hide comment
@enoch85

enoch85 Mar 20, 2015

Member

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!

Member

enoch85 commented Mar 20, 2015

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!

@enoch85 enoch85 closed this Mar 20, 2015

@Morganlej

This comment has been minimized.

Show comment
Hide comment
@Morganlej

Morganlej May 8, 2015

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)

Morganlej commented May 8, 2015

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

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 Oct 9, 2015

Member

It is by design.

We can keep the server ticket as enhancement request though.

Member

PVince81 commented Oct 9, 2015

It is by design.

We can keep the server ticket as enhancement request though.

@Morganlej

This comment has been minimized.

Show comment
Hide comment
@Morganlej

Morganlej Oct 9, 2015

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)

Morganlej commented Oct 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 Oct 9, 2015

Member

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

Member

PVince81 commented Oct 9, 2015

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

@carlaschroder

This comment has been minimized.

Show comment
Hide comment
@carlaschroder

carlaschroder Oct 9, 2015

@PVince81 There is not. Yet.

carlaschroder commented Oct 9, 2015

@PVince81 There is not. Yet.

@toddpfaff

This comment has been minimized.

Show comment
Hide comment
@toddpfaff

toddpfaff Dec 23, 2015

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 commented Dec 23, 2015

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

This comment has been minimized.

Show comment
Hide comment
@toddpfaff

toddpfaff Feb 3, 2016

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

toddpfaff commented Feb 3, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment