Folder mtime is not being preserved

[Juma7C9]

Hi, This is one of the original ownCloud issues, that was still debated prior the fork (Reference), and if I am correct, is still not resolved.

---

As stated before, this problem may affect many user's workflow (as it becomes impossible - for instance - to sort directories according to their creation/modification date), and as it was previously dismissed on performance/bandwidth usage grounds, it was also proposed to introduce this possibility as an optional switch.

Steps to reproduce

1. Copy some files and folders inside the Nextcloud local folder
2. Wait the folder to be synced with the server
3. Check modification time on the web interface

Or

1. Upload some files and folders using the web interface
2. Let the files to be synced to the local client(s)
3. Check local modification time

Or

1. Copy some files and directories inside the data/<User>/files directory preserving attributes
2. Run occ files:scan --all
3. Check modification time on web interface

Expected behaviour

Files and folders show both the correct original modification time

Actual behaviour

In all the three scenarios, while files show the original modification time, the directories' mtime becomes the time it was last synced in the first two cases, and the last time it was modified in the latter (regardless of the mtime of the directory on disk. This means that if some directory is being touch'ed and then occ files:scan --all is run twice, the mtime is updated only the first time, and it reflects the time of the first run.)

Server configuration

Debian 8.6 "Jessie"

Web server: Apache 2.4.10

Database: MySQL 5.5.52

PHP version: PHP 5.6.27

Nextcloud version: 10.0.1

Updated from an older Nextcloud/ownCloud or fresh install: Fresh install

[ckujau]

Why is this marked stale? The mtime is still not being preserved with the nextcloud-14.0.4. I know it's even documented, but it's still a bug from a user's POV :-\ Is there any way to get this resolved? Or is there a config toggle involved to switch from tracking "last uploaded" to "last modified"?

[kesselb]

@rullzer Is that fixed by filecache_extended?

[chainria]

This just bit me hard time. I accidentally deleted a folder tree, no biggie. Restored ti from the interface, ALL folder mtimes became current. What could have been a single click repair became a full blown restore operation because quite often metadata is as important as the data itself. Can this please be fixed in some upcoming version? Yes, I would settle for a configuration flag as well.

[rekster]

Why is this bug still not resolved? I'm having the same issue. Modification dates of folders are being set to the date they are synced, not the date of the folder on the source. This is creating major nightmares keeping track of things.

[chainria]

Why is this bug still not resolved? I'm having the same issue. Modification dates of folders are being set to the date they are synced, not the date of the folder on the source. This is creating major nightmares keeping track of things.

I don't know, but it seems to be in progress. I think this should/could be one choice the user could make. Filezilla has such an option for instance. Because I can think of some users absolutely not wanting this feature/option. But others, like me, absolutely rely on it.

[chainria]

After taking a good look at https://github.com/owncloud/core/issues/7009 I would propose the following solution:

• On initial sync, touch/update all mtimes, in the reverse order of the directory tree and cache the mtimes of the folders.
• On any incremental (DOWN) sync, re-apply mtimes if they changed, using the cached time. Again in the reverse order of depth. I guess the client uses inotify or some other mechanism like it, so it SHOULD know of directories changing mtime.
• On any incremental (UP) sync, push new mtimes to server.
• Oh, and not using temporary files in the synced folder itself should resolve quite some headaches as well.

Now, I know this must be a hell lot of work but yes, other solutions do it like this as well and I think Nextcloud should at least be in feature parity to further become popular. And I, and I am sure a lot of other users as well, will be very glad for this change.

That being said, if any tests are needed, I would gladly volunteer.

[Practicalbutterfly5]

This bug is annoying. I restored a backup from another cloud when I accidentally deleted some folders. And after running occ files:scan --all, those folders show as modified just now..😔

[pgy866]

I don't think the problem has been solved yet. https://github.com/owncloud/core/issues/7009

[gennaios]

Bump. Perhaps such hasn't been fixed yet since it may require a one time rescan of all files or perhaps instead an update on each folder listing at time of view. A very important issue for me. Perhaps already enough has been said. It would be as they say unacceptable if a local file system acted as such; same for remote or any file collecrion such as Nextcloud. I think no less important than file mtimes.