Re: User rw Permissions on New Hard Drive
- Date: Mon, 11 Mar 2019 13:46:33 -0500
- From: David Wright <deblis@xxxxxxxxxxxxxxxxx>
- Subject: Re: User rw Permissions on New Hard Drive
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.