You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
#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.The text was updated successfully, but these errors were encountered: