On Feb 7 20:38, Jeremy Drake via Cygwin-patches wrote: > They are exposed via the getmntent API and proc filesystem entries > dealing with mounts. This allows things like `df` to show volumes > that are only mounted on directories, not on drive letters. > > Addresses: https://cygwin.com/pipermail/cygwin/2025-February/257251.html > Signed-off-by: Jeremy Drake <cyg...@jdrake.com> > --- > Rather amazingly, this seemed to work as I expected. Kind of gross due to > keeping state in the _mytls.locals struct, but it seems to do the job. > Does this approach make sense, or is there something I'm missing?
The approach makes sense, but... On Feb 8 10:27, Jeremy Drake via Cygwin wrote: > On Sat, 8 Feb 2025, Corinna Vinschen via Cygwin wrote: > > Go for it. There's already matching logic in fhandler/proc.cc, > > function format_proc_partitions() for the "win-mounts" column > > of /proc/partitions. Probably this can be reused. > > Actually closer to the dos_drive_mappings at the end of mount.cc, except > that only looks at the first mount point. But, reusing anything might be > difficult due to having to save state and resume iteration on subsequent > calls. Open to suggestions on > https://cygwin.com/pipermail/cygwin-patches/2025q1/013353.html. Yes, dos_drive_mappings() is what I really meant, thanks for pointing it out. So I wonder why not include your additional requirements into the dos_drive_mappings class and just use it to iterate over the mount points. AFAICS there are only two things missing in dos_drive_mappings: - looking for all mount points, not just the first one, and - bookkeeping over getmntent calls If you add a state pointer (pointing to the current mapping) to dos_drive_mappings, you only need a single slot in the TLS, holding a pointer to your dos_drive_mappings instance. [...time passes...] Hang on, there might be a bug here... [...time passes...] Why do we keep the cygdrive state in cygtls anyway? From history I see that this has been the case since at least 2003. Per definition, getmntent isn't thread-safe at all, and getmntent_r is only thread-safe in that it keeps the data in a buffer provided by the caller. However, the state information is process-wide: if you call getmntent alternating in two different threads, they don't see the same set of drives, but only every second drive. At least this is the case on Linux. Don't we subvert expectations by handling getmentent thread-local? If I'm thinking to much outside the box, feel free to kick me. Thanks, Corinna
