Request auto-connect for dupex: removable-media, mount-observe, hardware-observe

store-requests
1

Hi,

I am the publisher of dupex (publisher ewitsolutions), a GTK4 desktop application that finds byte-identical duplicate files and helps the user decide which copies to remove. It is strictly confined, base: core24, and uses the gnome extension.

I would like to request auto-connect for three interfaces. home is already auto-connected and covers the common case; the three below are what the app needs to work on anything outside $HOME and to scan efficiently.

removable-media

The core use case for a duplicate finder is comparing a large external drive against the internal one — photo archives, backup disks, and NAS shares that the user mounted under /mnt or /media (for example a kernel CIFS mount at/mnt/nas). Without this interface those paths are simply not readable and the app cannot do the one thing it exists for.

The file-chooser portal does not solve this: when the user picks such a folder through the portal, the app receives a document-portal path that masks the real filesystem type, so even a successfully opened NAS folder is misidentified.

mount-observe

Read-only access to /proc/*/mountinfo. dupEx determines the storage medium of each scan path — SSD, spinning HDD, or network filesystem — before it starts, and mountinfo is how it maps a path to the block device or the remote share behind it. The medium decides the scan strategy: thread count, read-ahead and whether byte-comparison is worth doing in parallel at all. Choosing the HDD strategy on a NAS, or the SSD strategy on a spinning disk, costs a multiple of the runtime on large scans.

hardware-observe

Read-only access to /sys/block/<dev>/queue/rotational, the second half of the same detection: 0 means SSD/NVMe, 1 means a rotating disk. This is the only reliable way to tell the two apart, and it is read once per scan path at startup.

What happens without them

All three fail silently as Permission denied. The medium is reported as unknown, the pre-scan loses the basis for its thread choice, and external drives are invisible. The app detects this case and prints the missing interfaces plus the required snap connect commands into its output tab — but that is a workaround for a first run that already went wrong, not something a desktop user should have to do.

None of the three is used to modify anything; all reads are for the paths the user explicitly selected.

Thanks for taking a look.

2

This request has been added to the queue for review by the @reviewers team.

3

Hello @ewitsolutions :slight_smile:

Give the justification provided, your request makres sense to me. However I think that manual connection is a better option for all three requested interfaces for the reasons stated below:

  • removable media: While dupex doesn’t fall neatly into one of the supported categories mentioned here, the app’s core function is reading user-selected files on external drives, and without removable-media those paths are simply unreadable. So granting the interface but with manual-connection is more appropiate.
  • mount-observe: Mount arguments in /proc/*/mountinfo can contain sensitive information for network filesystems Auto-connecting at install time means the snap gains this access without the user making an informed choice. In addition, mount-observe is used for optimising the scan strategy, namely the app still functions without it. That is precisely the kind of optional, privileged access that manual connection is designed for.
  • hardware-observe: Since the app only needs a certain file subset: /sys/block/<dev>/queue/rotational, which is a perfectly reasonable thing to read, and hardware-observe grants far more than that one file, similarly manual-connection is preferable.

So +1 from my side for manually-connecting removable-media, mount-observe and hardware-observe interfaces to dupex.

4

Hello,

As this snap does not fall into any of the supported removable-media categories, this is a clear -1 from me for auto-connection.

When considering mount-observe and hardware-observe, I agree with @yomonokio that they are optional access focused on optimizing the scan, and therefore the user’s voice and understanding of the access they are allowing should be prioritized. As such, this is a -1 from me as well for granting auto-connection for these interfaces, +1 to continue with manual connection. Thank you.

5

Hello again @ewitsolutions :slight_smile:

Would you like us to proceed with granting the manual-connection for the requested interfaces?

6

Hi,

yes, please proceed with the manual-connection grant.

Thanks to you and @elisehdy for the review and for the clear reasoning — the distinction you drew is fair, and dupEx already works with it: on startup it checks which of the three interfaces are unconnected and prints the matching snap connect commands, so users are told what to do instead of silently getting a degraded scan.

Best regards, Andreas

1 Like
7

Hello again

In this case no further actin is needed from our side! Happy snapping :slight_smile: