On 2023-07-06, Bram Moolenaar <[email protected]> wrote:
>
>> On 2023-07-04, Bram Moolenaar <[email protected]> wrote:
>> >> Or, even better, one could create a (sufficiently large) RAM disk with
>> >> something like:
>> >>
>> >> hdiutil attach -nomount ram://204800
>> >> diskutil erasevolume APFS TempDisk /dev/diskN
>> >>
>> >> use it as volatile storage, then destroy it:
>> >>
>> >> diskutil eject /Volumes/TempDisk
>> >>
>> >> The RAM disk can likely be formatted with an encrypted file system, too.
>>
>> I was able to do that with the following commands; there is probably
>> a simpler way:
>>
>> hdiutil attach -nomount ram://20480
>>
>> This will return the path to the new device, e.g., /dev/disk4.
>>
>> diskutil erasevolume APFS TempDisk /dev/disk4
>>
>> This will initialize the disk. Unfortunately, this command does not
>> return the volume's path, which, for some reason, is /dev/disk5s1 (I
>> would have expected /dev/disk4s1).
>>
>> diskutil apfs deleteVolume disk5s1
>> diskutil apfs addVolume disk5 APFS encrypted -nomount -stdinpassphrase
>>
>> Enter a password. Finally, mount the encrypted volume:
>>
>> diskutil apfs unlockVolume disk5s1 -stdinpassphrase
>>
>> and enter the password.
>
> Does this give a prompt, does the user know when to type the password?
No prompt: that reads the password from stdin, then decrypts and mounts
the volume. If the password were to be read from a file called pwd.txt,
you would it in the obvious way:
diskutil apfs unlockVolume disk5s1 -stdinpassphrase <pwd.txt
>> > I can guess that "ram://" specifies using a RAM disk. What is the
>> > "204800" for?
>>
>> 204800 is the number of 512-byte sectors of the disk. So, the command
>> above will create a 100MB RAM disk.
>
> OK, so we divide the file size by 512 and use the resulting number.
> Or do we need to round it up to a multiple of 1024?
Rounding is not necessary (but it doesn't hurt), but a minimum size is.
About 20MB seems a safe lower bound.
Note, however, that the commands above will create something that looks
and behaves like a mounted volume, including with a mount point (e.g.,
/Volumes/TempDisk). Even if the file system is encrypted and volatile,
it will still be accessible like a normal volume to anyone with access
to the mount point as long as the disk is mounted (usual file system
permissions will apply to the content).
Is your purpose to include some macOS-specific mechanism for secure
inter-process communication to Vim? Maybe, that should be done using
some OS-specific API.
Life.
--
--
You received this message from the "vim_mac" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_mac/u87c64%2417du%241%40ciao.gmane.io.
