UI Precision and Trying to Make Sense of Lost Uploads

Purpose: continuous, reliable backup of all photos/videos of an iPhone in their original format, instead of mounting afc:// on my Ubuntu desktop and copying the files from DCIM/100APPLE.

Problem: NextCloud spuriously failed some files and the NextCloud iOS App does not provide me with enough information to verify

As things stands now, I cannot trust the NextCloud app to properly back up the iPhone. I have to hope that I do not lose the iPhone while outside, and I have to remember to plug it into my desktop and manually copy the files off it.

Steps to reproduce

1. Start with a new iPhone that has about 100 pictures and movies
2. Set up a fresh NextCloud account
3. Log onto NextCloud account
4. Nextcloud App > More > Settings > Advanced. Set Most Compatible to Off and Live Photo to On
5. Nextcloud App > More > Settings > Auto upload. Change filename mask: Set to Maintain original filename. Set Use subfolders to On. Set Upload the whole camera roll to On. Set Auto upload photos / videos both to On and set Only use Wi-Fi connection to On
6. Wait for Nextcloud App to complete the transfer
7. mount iPhone on regular Linux computer and copy DCIM/100APPLE to local drive for closer examination
8. compare files on the server with files copied directly

Expected behaviour

All the files from DCIM/100APPLE are copied 1:1 in subfolders on the NextCloud server, exactly the same including the same datetime stamp, and the exact same content (same filesize and vbindiff showing no difference)

Actual behaviour

timestamps on the Nextcloud server are all randomly messed. Some files are smaller on the NextCloud server than on the direct copied files. Out of approximately 100 files, at least one file had the extension renamed to small caps. And at least one file was missing. Here a few excerpt from ls -al

Nextcloud Server:

-rw-r--r-- 1 1000033 1000033  2356455 Oct 25 01:36 IMG_0001.HEIC
-rw-r--r-- 1 1000033 1000033  1349159 Jan  4 22:01 IMG_0001.mov
...
-rw-r--r-- 1 1000033 1000033  1599827 Oct 25 01:36 IMG_0019.HEIC
-rw-r--r-- 1 1000033 1000033   871683 Oct 25 01:36 IMG_0021.JPG
...
-rw-r--r-- 1 1000033 1000033    18362 Oct 25 01:36 IMG_0064.JPG
...
-rw-r--r-- 1 1000033 1000033 17189909 Oct 25 01:36 IMG_0093.MOV
-rw-r--r-- 1 1000033 1000033   381045 Oct 25 01:36 IMG_0094.PNG
-rw-r--r-- 1 1000033 1000033  2362614 Jan  3 16:55 IMG_0095.HEIC

Corresponding DCIM/100APPLE original:

-rw-rw-r-- 1 yuv yuv  2356455 Aug 11 10:47 IMG_0001.HEIC
-rw-rw-r-- 1 yuv yuv  2304827 Aug 11 10:47 IMG_0001.MOV
...
-rw-rw-r-- 1 yuv yuv  1599827 Aug 23 14:51 IMG_0019.HEIC
-rw-rw-r-- 1 yuv yuv  1043929 Aug 23 14:58 IMG_0020.JPG
-rw-rw-r-- 1 yuv yuv   871683 Aug 23 14:58 IMG_0021.JPG
...
-rw-rw-r-- 1 yuv yuv    22655 Sep  9 12:50 IMG_0064.JPG
...
-rw-rw-r-- 1 yuv yuv 38706284 Oct  5 15:50 IMG_0093.MOV
-rw-rw-r-- 1 yuv yuv   715031 Oct  6 15:02 IMG_0094.PNG
-rw-rw-r-- 1 yuv yuv  2362614 Oct 12 17:00 IMG_0095.HEIC

Screenshots

No useful screenshot. The iOS app only shows imprecise sizes and timestamps. The app would be much more useful if a user could toggle the file list between precise and imprecise notation; and between relative and absolute timestamps: all combinations have valid use cases. Forcing imprecise notation / relative timestamps and ignoring the other use cases by pushing them to some far away file-by-file detailed view makes the app useless for most file browsing.

Logs

Nothing unusual in the NextCloud Log, they all look like

Jan 31 02:40:34 nextcloud nextcloud nginx: 192.168.1.55 - yuv [31/Jan/2021:02:40:34 +0000] "PUT /remote.php/webdav/Photos/2020/07/IMG_0001.mov HTTP/1.1" 201 0 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/3.2.0"

Sorry, I do not know how to access iDevices' log

Reasoning or why should it be changed/implemented?

Reliability; Transparency; Usability

Reliability: the files on the server should mirror exactly the files on the device. Byte per byte (unless the user asks for "Most Compatible" which in my view is data loss: the processing to other format can happen after the source images are extracted.

Transparency: the user should be able to visually verify, at least that sizes and timestamps match (yes, it is a false sense of security, but it is better than currently).

Usability: showing imprecise sizes and relative timestamps may look slick, and it certainly has a use case. However, it is incomplete. When browsing a git repo on github it is fine because I do not need precision, just a sense for approximately how stale the repo is. However, when I browse pictures, I do need precise, absolute timestamps, e.g. to inform my decision of what time of the day to try to capture the same sunset atmosphere the next day. Relative timestamps cannot help with that, and many other uses. Imprecise file size are less problematic.

Environment data

iOS version: iOS 16.2

Nextcloud iOS app version: 4.6.0.19

Server operating system: Ubuntu 18.04LTS

Web server: nginx/1.22.1

Database: MariaDB 15.1

PHP version: 8.1.13

Nextcloud version: 25.0.2

Start with the listed reproduction steps using the Nextcloud iOS app, then compare the uploaded files against the iPhone's DCIM/100APPLE copies, including content, sizes, names, and timestamps. Review the app's auto-upload and file-list behavior; done would require an agreed scope that reliably preserves uploads and exposes sufficiently precise file information.