#1961 PTP_EC_ObjectInfoChanged is not propagated to clients, causing stale metadata for newly created Android files

[Anonymous]

I am seeing reproducible stale file metadata when using a Fairphone 5 via MTP on Ubuntu.

Environment:

• Ubuntu 24.04.5 LTS
• Nautilus 46.4
• GVFS 1.54.4-0ubuntu1~24.04.2
• libmtp 1.1.21-3.1ubuntu1
• Device: Fairphone 5 5G (FP5)
• USB mode: File Transfer / MTP

Steps to reproduce:

1. Connect the Fairphone 5 via USB and select File Transfer.
2. Open DCIM/Camera in Nautilus through the GVFS MTP mount.
3. Take a new photo on the phone while the MTP connection remains active.
4. Wait for the new JPEG to appear in Nautilus.

Actual result:
The new JPEG appears automatically, but its size is reported as 0 bytes. It cannot be opened as the full image.

A direct query through GVFS still reports the file as 0 bytes after waiting:

Größe: 0
standard::size: 0

The phone itself can display the photo normally.

Unmounting and remounting the MTP device immediately fixes the problem. After the remount, the same JPEG has its correct file size and can be opened normally.

The same Fairphone does not show this problem when connected to a Windows 11 system.

Expected result:
After the phone has finished creating the JPEG and sends an ObjectInfoChanged event, clients should be able to obtain the updated object metadata, including the final file size, without an MTP remount.

Debugging:
I reproduced the issue with GVFS MTP debugging enabled.

For the new photo, the phone first sends:

Received event PTP_EC_ObjectAdded in session 1
mtp: (II) check_event_cb: 0, 3, 1891

GVFS then adds the new object to its cache.

Shortly afterwards, the phone sends:

Received event PTP_EC_ObjectInfoChanged in session 1
mtp: (II) check_event_cb: 0, 0, 0

Subsequent GVFS QueryInfo calls continue to use the existing cache entry, and the file remains reported as 0 bytes.

mtp-detect reports that the Fairphone supports both:

• 0x4002: ObjectAdded
• 0x4007: ObjectInfoChanged

The difference between

PTP_EC_ObjectAdded
check_event_cb: 0, 3, 1891

and

PTP_EC_ObjectInfoChanged
check_event_cb: 0, 0, 0

seems significant.

Looking at the libmtp event handling, it appears that PTP_EC_ObjectAdded is exposed as a LIBMTP event with its object ID, while PTP_EC_ObjectInfoChanged may not currently be propagated to the client in the same way.

This would be consistent with the observed behaviour: GVFS receives the initial ObjectAdded notification and caches the preliminary metadata, but does not receive usable information when the object's metadata subsequently changes.

I have attached the relevant excerpt from the GVFS MTP debug log showing the complete ObjectAdded -> ObjectInfoChanged sequence.