Deleting child features/pictures in DCIM map of the (QFieldCloud) project not working

Hi, It’s been a while…

In a community project for volunteers I encounter a problem having the child features (in this case more then one picture for each parent feature) not being deleted in the DCIM folder/cloud. The project works with a relation to a separate table where the image paths are shown.

The project consists of a *.qgs project, a *.gpkg container, a .QfieldSync folder, a DCIM folder and a cloud_attachment folder. All these data are in the same folder as the *.qgs project.

In other words, I can delete parent features in QField and QGis and the child features will be deleted but the (child) pictures persists in the DCIM folder.

I did some research (*See list at the end) but I’m stuck…

1/ The relationship between parent and child layer was set correctly (using UUID) as ‘composition’. UUID was set as unique identifier.

2/ When I delete the parents on desktop (Windows 11 Enterprise and/or Linux Mint), QGis Tells me that it will delete 121 parents and 110 childs. That’s fine!

3/ In the configuration of the plugin QFieldSync all is set correctly

4/ Child table with pictures in has 233 features before deleting and 123 after deleting

5/ But in the DCIM local map of the QFieldCloud project map on desktop nothing changes… In other words, the pictures (‘childs’) are not deleted.

6/ If I would sync now from desktop to cloud, no pictures will be deleted…

7/ I think there is a problem with the path in the QGis project (lay-out form) to the local project map and I tried different options on the windows pc

  • C:\Users\struelma\QField\cloud\Vrijwilligers_Miradal_v1a
  • C:\Users\struelma\QField\cloud\Vrijwilligers_Miradal_v1a + ‘/DCIM’
  • C:\Users\struelma\QField\cloud\Vrijwilligers_Miradal_v1a + ‘\DCIM’
  • @project_home + ‘/DCIM’
  • @project_home + ‘\DCIM’

8/ Because the photos are not deleted in the DCIM map, they are of course not deleted in the cloud either.. When I manually delete 3 random pictures in the DCIM map, they are deleted in the cloud

*List of some related issues

Does anyone see the cause of the problem?

I’m not sure, but I think this might just be the expected behaviour and I don’t think you will be able to achieve what you want with this approach, due to a couple of point:

  • QField mostly just does what QGIS does, so if it doesn’t work on the desktop, it would most likely not work on mobile. So good think you already tried on desktop.
  • I don’t think you can delete a file on QGIS. You can add/create and edit them, but at least I’ve never seen a way to delete a file. You can delete a layer from a project, but it remains on disk, it doesn’t even ask you. You can delete a record on a database, and I’d imagine even the table if you want to, but not the database itself. Similarly, you can change the path to an image on a field on a record, but it doesn’t delete the image. I think this might come from the multi-user approach that is very common on GIS workflows, were deleting a file shared between potentially many projects and users is very unlikely and better left to a system admin.
  • In my experience, DB level system admins are very reluctant to deleting information and usually treat it like a very special case that is both expensive and potentially catastrophic. The mantra is that you can always unlink the information and add new records, but deleted information will sooner or later come to haunt you.
  • It seems like this issue has been previously discussed, like on this issue on github. There you can see that it’s not so clear how to handle an attachment deletion, at least if you try to maintain the QGIS approach.
  • To add the capability to automatically delete the image information might require a lot more involvement.
    • As mentioned on the previous link, you’ll have to first define all the usage parameters of the images (such as if it can be shared between multiple features or not).
    • I think that maybe the simplest approach would be to embed the images as a binary blob inside of the record of the feature, but I’m not sure how well this would scale.
    • Another approach might be to do an assisted manual deletion, outside of QGIS/QField (or maybe as a plugin), such as running a script that reads all the paths of all the images on all the features of your project and deletes all the missing/orphaned files of the same type.

Thanks for the answer @cuprico

I was hoping the QGIS approach was different but I understand. Anyway, for QFieldCloud users and (community) projects this is important information because the cloud storage is eaten up quickly this way. I found a helping hand to write me a python script as workaround. Perhaps an easier solution or workaround can be found for qfieldcloud users?

A python script is exactly the kind of thing I was thinking of, that’s a good asset to have.

I’m not an expert on the matter, so maybe someone else can better clarify this. For QField, I’d imagine the best and most straight forward way would be to make a plugin. I’ve never tried something like it, but maybe your python expert can check it out? Deleting the orphaned photos on the capturing device itself sounds like the best approach.

1 Like

@BoswachterMarc , greetings, nice to see your handle popping up on the community platform :slight_smile:

When deleting features, QField does not delete any associated attachments on the device. That’s to avoid data loss.

Now, if you have added a feature (and some children) within a session and - not having yet pushed the changes - subsequently delete that added feature and child[ren], their attachment will not be uploaded to QFieldCloud as the added then deleted feature will not track the attachment. However it remains on the device itself as a file in DCIM.

I’m happy to see you found a workaround using a python script. Feel most invited to share it here, I’m sure it will help others. Did you use the QFieldCloud python SDK for that?

Maybe someone can create a plugin to do this. The plugin could delete any files in DCIM that are not referenced in the project data.
I think the standard approach from QGIS (not deleting the data) is correct, but with QFieldCloud there is the added circumstance of storing data on a limited and paid for storage location.

I am not a plugin developer but I can imagine such a plugin has to be very carefully used.
Does it search, by itself, all fields in all datalayers for references to images?
Does it need to be told which fields to track?
Does it need a confirmation, per file deletion or for all files at once?
And how does QFieldCloud handle these deletions and version history? How long do these deleted files keep using storage?