On Sat 09 Mar 2019 at 20:31:36 (+0100), Pascal Hambourg wrote: > Le 08/03/2019 à 04:15, David Wright a écrit : > > On Thu 07 Mar 2019 at 23:12:29 (+0100), Pascal Hambourg wrote: > > > Le 07/03/2019 à 20:23, David Wright a écrit : > > > > > > > > A filesystem > > > > that has a label, has that label regardless of any OS. > > > > > > Have you ever used UDF ? > > > > Yes. As far as my experience goes, there's not a lot of difference. > > I've had no occasion to *write* DVDs on a computer system, so I can > > only speak of reading them. > > I did not mean using UDF on opticals discs but on regular drives, just > as any other general purpose filesystem. I once considered using it > for file sharing between Windows and Linux instead of the usual FAT > and NTFS. Indeed UDF is natively supported as a read-write filesystem > by both Linux and Windows, natively supports POSIX permissions and > does not suffer from FAT file size limitations. And I was surprised to > discover that the label set by Windows was not the label read by Linux > and vice versa.
Without reading a review of how it performs, I'd worry about using it as a general purpose filesystem. It sounds as if it's designed mainly for handling specific issues raised by particular devices. I might be happier if it were integrated into the kernel rather than just a user application. I might try it on a caddy or stick sometime. > > > It has a set of identifiers, and I observed > > > that Windows and blkid did not use the same identifier as the label. > > > > I've made no claim about what Windows and blkid do and do not use. > > You wrote that the filesystem label was independent of any OS. No, I wrote "A filesystem that has a label, has that label regardless of any OS." In other words, if you hold a filesystem (on a device) in your hands, the label is still present, as a property of the filesystem, written there as a sequence of characters. This is in contrast to the string /dev/disk/by-label/LABEL which is effectively an artefact of the operating system, dependant on the device being connected to a particular type of OS, and not written anywhere on the device itself. > I just > gave an example of a filesystem for which two different OSes use two > different identifiers as the label. I try to avoid ambiguity by using "LABEL" to refer to a string that's used as the value of mount -L or fstab's LABEL=, and by using plain "label" elsewhere. That's why I wrote "I'm not clear about which other sort of label might be referenced by LABEL=" at the end of that same posting you quoted from. The OP said they didn't have any other sort in mind either. So thank you for the example of UDF. I take it the set of identifiers is the following: --lvid=logical-volume-ident Specify the logical volume identifier. --vid=volume-ident Specify the volume identifier. --vsid=volume-set-ident Specify the volume set identifier. --fsid=file-set-ident Specify the file set identifier. It would appear that mkudffs tries to circumvent the problem by encouraging lvid and vid to be set to the same value. That said, I have no idea which of these two identifiers was reacting to the LABELs I read and gave to mount -L in the example from my DVDs. Would the "set identifiers" have something to do with the fact that the maximum file size is several millions of times bigger than the maximum volume size? Not a phenomenon I'm used to. Cheers, David.
