Open a-raccoon opened 2 years ago
A similar request I've seen, that would also be very cool, is the hybrid-idea of a singular VeraCrypt virtual drive letter (X:) that, itself, contains an array of mount point folders for each of the mounted volumes. All in one tidy place.
Thank you for reviving this subject on Github. I have started the implementation of this feature and for now I target only CLI support. I will try to publish a beta in a week or so. For the UI, I'm not sure what is the best way from UX point of view to expose this feature. Current ideas are:
As for the hybrid idea, I'm not sure yet how to implement it. Since the virtual driver letter should point to a valid filesystem, one idea would be mount a RAM disk to it and then create the mount point folders inside it. For now, VeraCrypt doesn't have support for RAM disks but it is possible to add it. We will see in the future how things go but if we implement the idea of slots, the user will have flexibility to organize his mount point folders as he wish.
Thanks. As far as UI suggestions go, I would say it's time to retire the A-Z drive plane and instead display a list of mounted volumes only. Maybe include in the list the favorite volumes that are unmounted and mounted. Maybe include in the list the detected devices without partitions, and detected partitions without volumes, as potentially unmounted.
As far as behind the scenes, make all mounts driveletter-agnostic unless the user specifies an override, otherwise, allow Windows to assign drive letters.
Add a field in mount option that allows choosing the folder when to mount
Rather: Add a field that allows choosing a letter OR a folder, otherwise, let Windows handle it and just show the volume to Windows without asserting either letter nor path.
I have started the implementation of this feature and for now I target only CLI support. I will try to publish a beta in a week or so.
- Add a field in mount option that allows choosing the folder when to mount
Hello @idrassi , I'm very interested in this feature. I moved from VeraCrypt containers to VHD for this lack of mountpoints configuration but I'm looking forward to go back to VC.
I've just found this answer of yours and downloaded the latest version but found nothing related to this implementation.
A CLI option would be perfect ! Has it been released or is it still in development ?
Best regards, V.
Any updates on this?
Great to see that such a feature is planned!
Would mounting to a folder inside an encrypted system drive also work? For this I assume a certain sequence of mounts would be necessary, e.g.
where 2. and 3. can't be mounted before 1. has been mounted.
As for UI/UX, a dynamic list of mounted drives would suffice, no need for the static list of A-Z.
I thought I'd let you guys know that there are still people interested in this feature even after all these years! Let us know if you plan to implement it.
I thought I'd let you guys know that there are still people interested in this feature even after all these years! Let us know if you plan to implement it.
Thanks @cajazt to keep our hope alive.
Looking at the SourceForge forums, there have been a dozen or more requests over the years asking for the ability to choose an NTFS folder as their encrypted volume's mount point, instead of assigning it to a drive letter. I wish to express the same interest, and chose to post on here in the hopes it will be better seen.
There is currently a way to approximate a folder mount point, but it requires the use of a batch script and the command
mountvol
to create the new folder mount and release the existing drive letter mount from the system. However, this has to be run every time the volume is mounted in VeraCrypt, and also, a drive letter must still be chosen within VeraCrypt and VeraCrypt continues to believe that letter is in use even after the letter has been released by the system. This can potentially cause VeraCrypt to behave unpredictably, or at the very least, still requires to manage volumes with drive letter management in mind.Here are the instructions on using the mountvol command.
Here is a script for automating the process.
I hope that drive letter dependency should one day become a thing of the past. :)