ImDisk RAM disk not shown on Windows even with -all

[FRex]

As in the title: the OS SSD, internal HDD and external USB 3.0 HDD are all shown correctly, but this ram disk (formatted to NTFS of course) is not, not even with -all.

This RAM disk is shown by the df command (I tried the one that came with git bash, the one that is in msys directory of Haskell Platform and the one in a Windows build of busybox, all three show it).

[RangerCD]

Is it shown in command fsutil volume list?

[FRex]

No, fsutil volume list (ran as admin in powershell) shows 5 'possible mountpoints'. Three of them are listed also as C, D and F. My ram disk is E and also missing.

Diskovery (from https://diskovery.io/ ) also doesn't show the ram drive but from its display (by the volume path GUIDs) I can tell the two mountpoints without letters are partitions on the C drive at the start (one is EFI, one is recovery) so they're not the ram disk.

[RangerCD]

Maybe MinGW(git bash, MSYS) made some kind of logical virtualization for RAM disk. But busybox-w32 claimed that it uses WIN32 API directly. I will do further research for this issue.

[FRex]

They do do something extra: df from Git Bash has C:/Program Files/Git mounted as / while busybox's doesn't. Git Bash also has /proc/mounts file present with all the mounts listed, but it's not accessible in busybox sh, or by its cat, or by other non-msys/non-cygwin Windows exes, so I assume df in busybox doesn't somehow read it.

But there is also bit set in WinAPI's GetLogicalDrives for the ram disk, and it of course appears in This Computer, Windows Explorer, as a drive to pick from the list of drives in WinDirStat, etc. (but doesn't appear in Disk Management tool, and the previously mentioned Diskovery, and duf).

[FRex]

Just for my own use I did it this way: FRex@2b7d398

It's a bit of a hack and copy paste, and it made me get Go 1.15 (I had 1.14, I think using GetLogicalDrives did it).
Maybe some check for each drive letter without this bitmap would be better to keep it 1.12+ as the README says.
If you want my commit or my commit minus GetLogicalDrives as a PR, let me know.

[RangerCD]

I think GetLogicalDriveStrings would provide more compatibility than GetLogicalDrives. And I'm also wondering whether this function covers mountpoints returned by FindFirstVolume and FindNextVolume.

[FRex]

What do you mean by more compatibility? And yes, a bit is set for each lettered[0] drive, so without the mountPointAlreadyPresent function some drives (C:\ for sure) would be listed twice.

[0] by lettered I mean mounted as a letter itself like C:, D:, and not mounted in some folder path.

[RangerCD]

Instead of a bitmap like GetLogicalDrives returns, GetLogicalDriveStrings returns a list of mountpoint path strings directly. Maybe someday Microsoft decides to extend drive letter, GetLogicalDriveStrings would be a better choice.🤔

[FRex]

I know of it, but how would they extend it if there is just letters from A to Z and the solution to have more drives is mounting them in folders? Add non-latin letters? 🤔

GetLogicalDriveStrings actually returns/fills a single buffer, which has nul terminated strings in it, plus two nuls at the end (so it's like a list of strings in a flat buffer plus empty string - where two nuls are next to each other - to mark the last element). That's more annoying to process (even in C) than bits, that's why I didn't use it.

And I remember GetLogicalDrives made go build demand I have Go version 1.15 (or I did something else that did it), will GetLogicalDriveStrings do the same? I ask since you advertise working on Go 1.12 and up in the README. I can do a syscall myself if that's the issue.

If you're set on it I can make a PR with GetLogicalDriveStrings, direct syscall it (if needed to not require Go 1.15 which I can double check). Any other issues with my personal fix commit (like the 90% copy pasted getMountFromMountPoint function 🙃) you'd want changed?

[RangerCD]

Well, nobody knows how Microsoft would extend drive letters. But on the other hand, maybe GetLogicalDriveStrings includes those drives mounted under a folder, that would be a good reason to use if it really do.

[FRex]

I will check in the evening, and rewrite my commit to use it instead of the bitmap.

[RangerCD]

I'm sorry that I can't check it by myself now. I'm currently on vacation, and I didn't take a Windows device with me.

[FRex]

1. Here it is: FRex@f91de5a
2. Here it is squished with my previous commit: FRex@17b896b
3. It's more code and feels more error prone and tedious compared to using GetLogicalDrives.
4. GetLogicalDriveStrings only returns letter mount points.

[RangerCD]

3. It's more code and feels more error prone and tedious compared to using GetLogicalDrives.

Totally agree, it's not worth using GetLogicalDriveStrings if it returns the same result as GetLogicalDrives does.
I've made some adjustment from FRex@2b7d398 which is the GetLogicalDrives commit, please review PR #91.

[FRex]

Iterating "A" to "Z" instead of numbers, putting appendLogicalDrives last (there could be a comment for why this exists, even mentioning ImDisk by name as example, and to explain why it has to be last to not duplicate drives, I left a comment in the PR about that) and deduplicating the getMount function are all good.

But why is now Mount's field Mountpoint set to guid for both GUID and network drives (but not for ones from the bitmap)? Before it was Device field that got set to GUID (if the volumeName local was empty). I left comments in 2 places in the PR for that.

The RAM Disk also has empty field Device now and thus empty FILESYSTEM column in the output ("device" field in JSON output). In my commit if volumeName was empty (which it is for that ram disk) it'd get replaced by the mount point too (like it happened with GUIDs originally) so the column isn't empty for that drive. I left a comment for that in the PR.

[RangerCD]

It was my mistake that I confused Device with Mountpoint, and that perfectly explains why we should simplify these codes. 🤦‍♂️