qfieldsync asks to sync layers that have not been modified

[kiri03]

I have a project set up with some read-only vector layers placed to show in the background, as a reference for the field editors.
Those layers, although they are set as read-only, are not edited or modified by any user, but despite this, whenever I synchronize from QGIS, it asks me to reload those layers from the cloud, as if they had been modified by some editor.
Is there a way to configure those vector layers so that they stay locked and don't try to download every time I sync the project from the cloud to QGIS?

Thanks.

[UlfEichelquetscher]

Hey kiri03,
I dont know an answer to your problem, but im curious, where you can set up the layer. Have you done it in the cloud or in QGIS?
Sorry for not helping :o

[gisDS]

Hello @kiri03,

We have the same problem, when we try to sync from cloud. We identify that every time that upload or sync from device Qfiled Cloud create a new file GPKG despite that layers in the GPKG are not edited or edited by any user.

We have tried all. We have created field UUID´s, . When we try to sync in Qgis the plugin download a new read-only file everey time. We need urgent help, if someone know how to fix that... I appreciate your help

[wanderingnature]

This is likely due to how QGIS save GPKG files. Every time you open a project and close it the GPKG files are updated whether or not there are any changes. I just manually uncheck the files every time when I don't make any changes to keep from having multiple versions on the cloud.

[idantene]

Bumping this still; this feels like a must-have.
We have a very large read-only geopackage for the same reasons. Having to re-upload it every time not only takes a very long time from our users (which then sometimes ends up with a failed upload), but it also requires more storage space on the cloud, which means we need to pay more for it.

As a stop gap solution, I've limited the number of historical copies to 1, which retains the project at a reasonable size, but we then of course have no historical data.

I'd expect some kind of option in the "Action" for Individual Layer Settings to set a file-based layer to "read-only" or "copy" (only download from the cloud once, do not repackage or upload when sync'ing back).

[nirvn]

@idantene , what is the action associated to your read-only geopackage in the project properties QField panel's QFieldCloud section?

[idantene]

It is set to Offline editing. In the Cable Export section, it is set to Copy.

To be honest, I find the documentation regarding the actions (QFieldCloud, Cable Export, and the layer actions) to be lacking.
It would be great to improve on that.
Would you be able to elaborate on the options and differences between e.g. Cable Export and QFieldCloud sections, as well as the available options? I could only find this, but it did not explain the nuances between QFieldCloud and Cable Export, for example.

[nirvn]

@idantene , that's your problem right there. If you set the layer to offline editing, it will be offlined'ed into data.gpkg, and subsequently restored. Use 'directly access data source'.

As for the cable export panel, you can ignore, it is of no consequence to cloud project handling.

[idantene]

Thanks @nirvn! I'll give it a go now.
Can you provide a brief explanation about how these options actually work from the cloud packaging point of view?

[idantene]

Quick follow-up @nirvn, I still occasionally get failed Delta Apply in QFieldCloud, and when I look at the logs, I see the following in the last step (Upload project) (layer names redacted):

08:31:12.432 root      INFO     Getting project files list…
08:31:14.725 root      INFO     Local files list for project UUID:
Name                                               Size  MD5 Checksum
--------------------------------------------  ---------  --------------------------------
my_project.qgs                 267706  1b010acc522afa833e444a0ae594da63
my_project_attachments.zip       2110  1a62b963f358f6027314480a908ebd89
options.csv                          66  1a4c2f4dc5e149b8b472401e39bc24bc
field_data.gpkg                                  106496  ac1fd2806ac75d45f4c6ad285896baa1
fixed_layer.gpkg                       930824192  cb3ef1c17ba313f71d7ae0893d4df2d7
raster1.tif                                    81462946  4d7d0d6ed63fff6724691b080876220a
raster2.tif                                  108372107  d3b8c67a02d9f5f054e2b1433b92d4ec
08:31:14.726 root      INFO     Uploading project files…
08:31:17.206 /usr/local/lib/python3.10/dist-packages/qfieldcloud_sdk/sdk.py INFO     Uploading file "fixed_layer.gpkg"…

Even though fixed_layer.gpkg is now set to Directly access data source, and the only change actually happens in field_data.gpkg. On a succesfull Delta Apply job, I also see it uploads the rasters.
This could be just a wording issue at this point, but it looks weird and does not provide any additional information why the Delta Apply failed..?

EDIT: Adding more information.
I compared the MD5 checksums for the Download Project Directory and Upload Project steps, on both the successful and failed jobs. I noticed two things:

• First, the raster layers have the exact same MD5 checksum, yet they're still uploaded. This suggests then the remote file's name attribute is incorrect or does not match the local file's name?
• Secondly, the fixed_layer.gpkg does have a different checksum, though their file size is identical and of course the layer has not gone through any changes.

I'd imagine the delta fails due to the 10min processing limit, but it seems like these files should not be uploaded. I could make a ticket from this, if needed?

[suricactus]

Hey, @kiri03 and @idantene , sorry for the late reply, I just found this issue. The problem you described should no longer be the case for a few weeks on app.qfield.cloud. I am closing the issue.