# Why is 23.0.1 so heavily delayed?

**URL:** <https://help.nextcloud.com/t/why-is-23-0-1-so-heavily-delayed/132133>\
**Category:** 🏷️ General\
**Tags:** nc23, release\_shedule\
**Created:** [January 28, 2022, 7:57am UTC](https://help.nextcloud.com/t/why-is-23-0-1-so-heavily-delayed/132133 "2022-01-28T07:57:09Z")\
**Posts on this page:** 1\
**Showing post:** 31

<div class="post-metadata">

**Author:** ![wwe](https://help.nextcloud.com/user_avatar/help.nextcloud.com/wwe/32/72963_2.png) [@wwe](https://help.nextcloud.com/u/wwe)\
**Post date:** [February 2, 2022, 8:19pm UTC](https://help.nextcloud.com/t/why-is-23-0-1-so-heavily-delayed/132133/31 "2022-02-02T20:19:14Z")

</div>

in some maybe not all situation there is a way to recover the mtime from versions file (or it’s DB record).

> [@Desktop client 3.4.0 destroys local time stamp and keeps uploading data to server](https://help.nextcloud.com/t/desktop-client-3-4-0-destroys-local-time-stamp-and-keeps-uploading-data-to-server/128512/54):
>
> I tryed hard to find a universal solution to link the file damaged by the sync with valid versions and allow subsequent recovery… at the moment my sql skills only allow this summary of intermediate steps which hopefully helps others. for some really strange reason there is no clear relation (in terms of unique ID) between the files and their versions… both are listed in the oc\_filecache table… the only difference is real files have prefix files/ while versions have files\_versions/ prefix and …

I didn’t find time to build reliable recovery procedure from this information as I’m not an expert in mysql but it _should_ work as following:

- find files with invalid mtime
- find the **most recent** version (if many) of the file which has **valid** mtime
- perform one of the possible recovery options:
  1. **safe** : touch the file with valid mtime (and remove version in 2nd step)
  2. **storage efficient** : move version file to the original location and overwrite bad file

- perform `occ files:scan all`

additional sugar:

- compare the version file you use for recovery with the file in the system (diff/checksum) - AFAIK the contents are unchanged, so file contents and versions should be same
- remove newer versions having invalid mtime (there are [github reports](https://github.com/nextcloud/desktop/issues/4016#issuecomment-984073905) when upload with invalid mtime happened multiple times)

I didn’t investigate further - NC devs might know from the top of the head - i think oc\_filecache table is not separated by user so if collect the information from DB you don’t need to iterate over each user to identify and recover the files, it _should_ work in one go..

---

_[View the full topic](https://help.nextcloud.com/t/why-is-23-0-1-so-heavily-delayed/132133)._