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

Form attachments are always updated on disk, even when they haven't changed #6437

Open
lognaturel opened this issue Oct 1, 2024 · 2 comments

Comments

@lognaturel
Copy link
Member

lognaturel commented Oct 1, 2024

#6432 (comment)

They're not redownloaded, but they are copied over again which resets the timestamps. This means there isn't a way to reliably tell which form attachments were updated when.

Ideally we could leave form attachments alone when the manifest hash means it doesn't need to be updated. It makes sense that attachments that need to be updated would be downloaded to a temporary folder because this guarantees that an interrupted update doesn't leave the form in a partially updated state. But ideally existing attachments that don't need to be updated wouldn't get copied to temp and then copied back.

I started looking at this because a user reported some unexpected extra -media folders on their device. They have a form with an attached Entity List and they had a few directories with snapshots of the entity list at different points in time. Maybe sometimes the cleanup isn't complete? Although I would expect those to be saved in a temporary directory, not in a -media directory.

Another user has now reported an issue with updating an Entity List attached to a form that also has a lot of attached images. The images haven't changed but the Entity List has. The expectation would be for the update to be very fast but it's taking a very long time. Killing the app and restarting seems to consistently make it possible to get a fast update. Previously this user had the same form structure with a static CSV rather than an Entity List and did not have this problem. This suggests there's an issue with how in-place updates are made.

This second user also has extra -media directories.

@seadowg
Copy link
Member

seadowg commented Oct 9, 2024

@lognaturel could you flesh out what the problem is here?

@lognaturel
Copy link
Member Author

I have added additional details.

@seadowg seadowg added this to the v2024.4 milestone Oct 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: not ready
Development

No branches or pull requests

2 participants