How can I fix incorrect date info for a directory?

ℹ️ Support
1

Hi community ,
my nextcloud 17 stopped working, probably caused by a server overload. The result was that i got a PHP error message
] [php7:error] [pid 21059] [client 2.244.66.235:63583] PHP Fatal error: DateTime::__construct(): Timezone database is corrupt - this should never happen! in /var/www/html/nextcloud/lib/public/AppFramework/Http/FileDisplayResponse.php on line 56

After restarting apache, nextcloud works again, but web access for one of the user directories shows a date and time far into the future (somewhere in the year 4500!) . This goes for only one of the many directories and subdirectories (at least I haven’t found any more :face_with_raised_eyebrow: )
The subdirectories beneath the one with the incorrect date show correct date and time infos. Physically, in the server data directory, everything looks correct.

So, it seems it is a problem of the nextcloud structure. Probably in one of the mysql tables there is this wrong date. Can someon point me to a possibe solution?

Thanks for reading
MIke

2

Please check the directory date on the console using the stat command. If this is ok, you can use the occ files:scan ...command to update the database.

3

Thank you, j-ed, for pointing me to the stat command. Very much hidden in a subdirectory, I found the bad guy with a mtime flag deep in the past:

File: ‘Flyer - Mal dich stark.pdf’
Size: 6846263 Blocks: 13376 IO Block: 4096 regular file
Device: 6850b641h/1750120001d Inode: 6425310 Links: 1
Access: 2020-07-26 13:58:33.613458807 +0200
Modify: 1915-01-23 22:02:56.000000000 +0100
Change: 2020-07-13 13:45:11.190947188 +0200

The 1915 date probably translates into the future, thus showing a date in the year 4500 in the nextcloud web interface.
As these are customer data, I don’t feel like touching the content of the file. But I set the mtime attribute
to some reasonable value, will nextcloud correct its tables when I redo the occ:scan?

Mike

4

You can use the touch command to change the modification date of a file:

https://www.thegeekstuff.com/2012/11/linux-touch-command/

5

j-ed, thank you for hinting to “touch”. I have altered the mtime attribute for the file in question, such that stat now shows:

File: ‘Flyer - Mal dich stark.pdf’
Size: 6846263 Blocks: 13376 IO Block: 4096 regular file
Device: 6850b641h/1750120001d Inode: 6425447 Links: 1
Access: (0644/-rw-r–r–) Uid: ( 33/www-data) Gid: ( 33/www-data)
Access: 2020-07-26 22:39:17.883431547 +0200
Modify: 2020-07-26 22:23:36.505969660 +0200
Change: 2020-07-26 22:39:17.153419557 +0200

“stat” on the the top level directory of this file, which is “team-bonn”, shows

File: 'team-bonn'
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: 6850b641h/1750120001d   Inode: 5376414     Links: 12
Access: (0755/drwxr-xr-x)  Uid: (   33/www-data)   Gid: (   33/www-data)
Access: 2020-07-27 09:18:33.506950511 +0200
Modify: 2020-07-06 06:43:01.138606389 +0200
Change: 2020-07-06 06:43:01.138606389 +0200

Consequently, everything should be OK.

In the mysql-nextcloud-table “oc_filecache”, however, I still find an mtime entry for the top level directory “team-bonn”, which points into the future:

files/team-bonn a9846e72d276ab5645bbb8fe0748c9a1 113 team-bonn 2 1 44414444845 79870665600 1594010581 0

“79870665600” converts to “Sat, 01 Jan 4501 00:00:00 GMT”, which is what shows on the nextcloud web page.
As the stat command on this directory seems OK, I am not sure what to do now.

6

Have you updated the file table by executing occ files:scan ...? You can also try to clear the web server caches by restarting the instances if this doesn’t help.