Skip to content
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

upama cache needs periodic flushing #88

Open
wujastyk opened this issue Sep 14, 2024 · 5 comments
Open

upama cache needs periodic flushing #88

wujastyk opened this issue Sep 14, 2024 · 5 comments

Comments

@wujastyk
Copy link

Running upama/dokuwiki/apache2 on my local laptop.

I find sometimes generating an apparatus does not use the latest versions of the files in data/pages. It seems, rather, to be pulling data from /var/www/html/dokuwiki/data/cache/upama. If I delete that cache/upama folder and re-generate the apparatus, it correctly collates the files in data/pages.

Dominik

@chchch
Copy link
Owner

chchch commented Sep 18, 2024

Upama checks the timestamp of the cache files and compares them with the files in data/pages... it could be that the timestamps of your pages aren't being updated?

@wujastyk
Copy link
Author

Hmm. The files are being updated, but the files in /var/www are hard links to the main file directory in my working area. I'll look into whether the time stamp of linked files are updated when the other file is updated.

<few minutes later> I think that's not it. I'm updating the main files; the content of the files linked by ln to the main files is being updated and their timestamps are also updated. And saktumiva displays the updated, linked file just fine.

It's something else. Maybe Dropbox (my "main" files are in a Dropbox folder and get updated by Dropbox when I'm working on another machine). I have a feeling that files updated by Dropbox have their ln links broken.

I'll keep checking.

Is there a downside to deleting the upama/cache directory? I've not noticed a downside so far.

@wujastyk
Copy link
Author

wujastyk commented Sep 29, 2024

This morning there was a particularly clear case. In my provisional ed., I had a reading "ullika". In an older version of the file, there had been a reading "ullikajā". I had corrected it. The file in /var/www definitely reads "ullika".
I load the file into Saktumiva, running locally, and I see "ullika". I collate the MSS, and the reading reverts to "ullikajā". That must be coming from some old cache. Refreshing the screen etc. doesn't cure the problem.

Deleting /var/www/html/dokuwiki/data/cache/upama and re-collating fixed the problem.

charles-2024-09-29_10.32.51.mp4

@chchch
Copy link
Owner

chchch commented Sep 29, 2024

Hmm yes maybe check the timestamps on your files in /var/www; do they get updated when you update a file?
There's no problem with clearing the cache -- it just makes the collation take a bit longer.

@wujastyk
Copy link
Author

The files in /var/www are hard-linked to the files in my main project directory, elsewhere on my disk.
When I open my file system manager (Nemo) with two display windows and update a project file, the windown showing the project file updates the date immediately. But the window showing the hard-linked files does not update the timestamp until I refresh the window. I don't know what this means. Is it an artefact of the file manager? Or is there something about file synchronization happening because of the hard-linking. The time-stamp is updated, but it doesn't display as updated until the display refresh. Could something like this be affecting the Upama cache?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants