I now āsort of reverse engineeredā the āoc_filecacheā table and have built a āhookā into that table of NextCloud and use it for itās cloud-drive capabilities and file management structure.
This is all working quite nicely, but when a file is moved the only way to process that change seems to do a complete database scan and compare the NextCloud table āoc_filecacheā to my table. This takes quit a long timeā¦
The field mtime holds the file date, so the storage_mtime appears to be an internal date.
Detecting a new/newer file is now done using the field storage_mtime
But I canāt see a āfile moveā nor a āfile renameā in the table, since the storage_mtime does not update/change.
In my opinion the field āstorage_mtimeā should also be updated to ānowā upon a move or a rename.
I would like to see this update done in a future version of Nextcloud, but could it be possible to build a āevent dispatchā to do this as a āquick fixā?
I canāt really help regarding the dispatcher, but I really wonder if hooking into the database (especially filescacheā¦) makes sense. Which underlying issue are you trying to solve?
I use Nextcloud for the NextCloud desktop client so I can use the network drive functionality, file management structure and the technology to use the S3 data storage technique.
With that I have the perfect bases to manage the vast amount of media for my History platform I call GeoArchive. an example:
Hooking into the āoc_filecacheā gives me access to the files. Hooking into the S3-account gives me access to the source files.
Combining that I can generate the images for my Archive project.
New additions to the Nextcloud account can easily be found by searching for newer file IDās then the last one I synced. File modifications can easily be found via the mentioned storage_mtime field.
But I now need to periodically sync the complete table. This is quite an intensive process. Especially when an archive has some 100.000 media elementsā¦
So I would really like to improve the incremental synchronization, especially the file moves and the renamesā¦
PS: a periodic full sync remains a smart thing to doā¦ but the whole performance of the Archive platform would greatly be improved if I could ācatchā the ārenames & movesāā¦
I think you do not want to create a custom event dispatcher but an event listener. There are a set of events that the core will trigger. E.g. OCP\Files\Events\Node\NodeRenamedEvent will be fired upon a rename of a file (move).
In an app, you could create a listener to react somehow (and this is how you handle the updating in your part). By the means of the event object, you can access old and new file name etc. Similarly, you can go with the other file system modifications.
