Seems a bit weird to want to have disks but not their path or even their kind. I think the best course would be to instead detect when the canonicalize call is actually needed and only call it if so.

Seems a bit weird to want to have disks but not their path or even their kind.

I was thinking those would be present in the new_with_list return. Only the information obtained from statvfs would be deferred.

I think the best course would be to instead detect when the canonicalize call is actually needed and only call it if so.

Hummm. Canonicalize (on linux) IIUC is just realpath. How would one decide if it were necessary? (I think you'd end up reimplementing almost all of realpath, right?)

The kind is retrieved from the function using canonicalize, so both functions would get a call to it.

Hummm. Canonicalize (on linux) IIUC is just realpath. How would one decide if it were necessary? (I think you'd end up reimplementing almost all of realpath, right?)

Mostly checking if it's a link, if not, checking if it doesn't start with / or contains .. (still not great to check that ourselves).

Any clue why statvfs is emitting this warning?

The kind is retrieved from the function using canonicalize, so both functions would get a call to it.

Ah, I see. I was thinking about vfstype, not DiskKind. You're right that DiskKind requires the canonicalize.

So in my suggestion, I guess the populated fields would be device_name, file_system and mount_point; the other fields would require a refresh.

Any clue why statvfs is emitting this warning?

I believe it happens during the canonicalize, not the statvfs. And it's coming from SELinux or apparmor or some similar system for permissions above and beyond POSIX. The fact that it emits these audit warnings in addition to failing the syscall is super annoying, at least in this instance :/

I think DiskKind is part of the fundamental information for a Disk, so I'm not super open to the idea of not having it by default.

However the RefreshKind approach for Disks sounds pretty good, just not sure there are enough different fields to make it relevant currently.

I'm not sure what you mean about RefreshKind, can you elaborate?

Sure. Like for refresh_processes_specifics: you can pick what you want to refresh with ProcessRefreshKind.

Ahh, I see. That's perfect! I'd be happy to extend that pattern over Disks. So I think I would:

• add a DiskRefreshKind
• add a Disks::new_with_specifics() constructor
• add a Disks::refresh_specifics() refresher
• add a Disk::refresh_specifics() refresher
• make (at least) the linux impl respect the specific refresh kind(s)

... sound about right? That would work for me :)

Yes but that wouldn't solve your problem since I still want DiskKind to be retrieved for all Disk unconditionally. ^^'

What if you always get DiskKind unless you specifically ask not to get it?

That could work. Only question, what value do you put into DiskKind::Unknown? It's supposed to mean something to the OS.

I'm not sure. I don't use the DiskKind, personally. The idiomatic Rust thing would be to make it Option<DiskKind>, but I'm guessing that's exactly what you want to avoid. Could we add another enum variant (DiskKind::NeedsReload)?

Indeed, I don't want an Option. I'm still wondering if we're not trying to go around a technical issue that could be fixed instead...

FWIW: even if it weren't for the annoying warnings, I would still use this functionality, since I'm currently loading way more information than I actually need :)

We can do it in two passes then: a PR to implement the selective refresh and another where we can debate what's best for DiskKind.

Look for a PR early next week!

Thanks in advance!