Hacker News Reader

Comment by mircea | Hacker News Reader

There's a real gem in that thread:

> FYI: There is also another cross-platform filesystem (Linux kernel, Windows NT kernel, Mac OS X kernel) suitable for hard disks too with POSIX permissions about which people do not know too much. It is UDF.

As I was struggling to find a way to share data between Linux/Windows with my gpu-passthrough setup, I'm excited to use this.

I think I've read something about 9p support in the latest Windows versions and I think QEMU supports 9p so that might become a good solution, too.

View on HN

There are several platform specific gotchas with UDF. If you want to use UDF on a drive, I suggest using the script at https://github.com/JElchison/format-udf. It takes into account the platform specific gotchas and formats a drive properly to be usable across Windows, Linux and macOS.

Yes. That script is really good!

Any chance that there's a way to actually encrypt a device set up like that?

I usually use LUKS and EXT4 for all my drives but lately I've needed to move files to and from Windows systems on occasion, and it kills me that (from what I can tell) there are absolutely no solutions that even attempt to do something like this.

Does everyone just walk around with unencrypted portable media? I don't really want to float sensitive data on unencrypted drives, even temporarily, since that makes the data vulnerable to things like wear leveling analysis etc.

mkudffs (a.k.a. mkfs.udf) on the whole block device, by default it uses --bootarea=erase, and results in a device that automounts on macOS, Windows 10, and GNOME and KDE (at least).

There is also --bootarea=mbr which sounds similar to what this script is doing but I'm not sure why it's necessary; maybe for older versions of Windows.

Windows works fine with flash drives without a partition table but can have issues with hard drives without one.

Sadly Microsoft and Apple have gone out of their way to make it difficult to access the same UDF filesystem from both Windows and macOS.

macOS will only access a UDF filesystem created on a disk device. Windows will only access one created inside a partition.

Linux, naturally, has no problem handling both. ;)

A sibling comment linked https://github.com/JElchison/format-udf which claims that it creates a whole-device FS which works across all 3.

9p is not a file system but a byte oriented file based RPC protocol for transferring data. In plan 9 the idea is files are objects in the programming sense which you create/open/read/write/remove/close. Example: your mouse is a file, /dev/mouse, which you open to read the coordinates and click events.

In plan 9 files are served by file servers, programs which speak 9p. The plan 9 kernel knows nothing of disks or file systems living on those disks. In fact, you don't mount disks in plan 9, you mount 9p connections. So to access files on a Fat formatted disk you need a file server program called dossrv(4) which opens the disk file and listens for 9p messages and performs the necessary Fat operations.

Fun fact: A common plan 9 newbie mistake is to mount a disk file directly as in Unix. This causes the kernel to write a 9p T_attach message to the beginning of the disk overwriting the boot sector. http://man.postnix.pw/9front/5/attach

I've used it before for a USB drive and honestly I have had nothing but problems with it. I don't remember exactly what kind of problems but I do remember that I was frustrated enough after some time to switch to something else.

If you want to try out the ntfs-3 driver, it is already in the XanMod kernel.

I've dug out some more details re:Windows 9p support. See under "How it works": https://devblogs.microsoft.com/commandline/whats-new-for-wsl...

Ironically, Google's Pixel build of Android does not include UDF support - the filesystem does not work on a USB stick like FAT32...

Actually for those plus freebsd, you could theoretically add openzfs - portable, support for permissions and native encryption support.

I'm trying to find it without success, does udf support journaling (or some form of recovery after an unclean reboot)?

From https://sites.google.com/site/udfintro/ :

> Although an implementation may use a journal to protect metadata integrity, this does not guarantee interoperability between platforms since it is not part of the standard.

it seems it's left up to the implementation.

Non-interoperability of a journal isn't a massive downside. It just means after a system failure, you need to plug it back into the same OS first.

Obviously that needs to be enforced with some kind of "do not mount" option so it isn't accidentally used on another OS.

For USB drives, it means that if you take it out from your work PC in a hurry, it might not be usable on your home Mac. Pretty serious I would say.

Reply on news.ycombinator.com