GET /sharings/drives carries no metadata for a drive whose root is a file

[Crash--]

A shared drive can have a single file as its root (drive_root_type: "file"). Clients list those drives from GET /sharings/drives, which returns the sharing documents: the only thing they learn about the file is rules[0].title (its name) and rules[0].mime. Rule (model/sharing/rule.go) carries no size and no dates, and APISharing adds nothing about the shared document.

So every client shows such a row without size and without a date:

• twake-drive web builds the row from the sharing alone (useTransformFolderListHasSharedDriveShortcuts — name + mime + drive_root_type), and the size column stays empty;
• twake-drive-mobile has the same gap, and the row also has no date to sort on, so it cannot take part in a sort by date.

The document itself is reachable, but only one request at a time: GET /sharings/drives/<driveId>/<file-id>. Filling a listing of N drives then costs N extra proxied requests, for a recipient each one going to the owner instance.

Could the listing carry the root document, the way a directory listing carries its children? The handler already resolves it (s.GetFileDriveRoot(inst) / GetSharingDir), so ListSharedDrives could include the file document (or at least size, updated_at, class) next to each drive.

Seen on a Twake Drive instance with several file-root drives (.docx, .excalidraw), against both clients.

[Crash--]

Checked on a Twake Drive instance, and the gap is worse than "no size": a client that falls back on what it does have ends up showing a wrong number.

For a recipient, the drive also exists as a .url shortcut under io.cozy.files.shared-drives-dir, referenced_by the sharing. That shortcut is a real file document, so it has a size — 157 bytes, the size of the .url itself — and the same 157 bytes for every drive, whatever the shared document is.

twake-drive web builds its row from that shortcut when it finds one (useTransformFolderListHasSharedDriveShortcuts keeps the shortcut fields and stamps the drive metadata on top), so a .docx and a .cozy-note shared as drives both show 157 o in the sharings list instead of their real size. Verified on two file-root drives of the same instance: the shortcuts are 157 bytes each, and neither root document is in the recipient replica, so nothing else can fill the column.

twake-drive-mobile leaves the column empty rather than show the shortcut size, which is why the two clients disagree on the same drive.

Either way the listing is the missing piece: with the root document (or just size, updated_at, class) next to each drive, both clients would show the document, and the sharings list could sort those rows by date like the others.

[Crash--]