Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #205840 > unrolled thread

User rw Permissions on New Hard Drive

Back to article view | Back to linux.debian.user

Contents

  User rw Permissions on New Hard Drive "Stephen P. Molnar" <s.molnar@sbcglobal.net> - 2019-02-28 21:50 +0100
    Re: User rw Permissions on New Hard Drive Dekks Herton <dekkzz78@gmail.com> - 2019-03-01 02:00 +0100
    Re: User rw Permissions on New Hard Drive David Wright <deblis@lionunicorn.co.uk> - 2019-03-01 03:30 +0100
      Re: User rw Permissions on New Hard Drive Felix Miata <mrmazda@earthlink.net> - 2019-03-01 04:50 +0100
        Re: User rw Permissions on New Hard Drive Cindy-Sue Causey <butterflybytes@gmail.com> - 2019-03-01 07:40 +0100
          Re: string "defaults" in fstab options columns (was: User rw  Permissions on New Hard Drive) Felix Miata <mrmazda@earthlink.net> - 2019-03-01 09:00 +0100
            Re: string "defaults" in fstab options columns (was: User rw  Permissions on New Hard Drive) David Wright <deblis@lionunicorn.co.uk> - 2019-03-01 18:00 +0100
              Re: string "defaults" in fstab options columns Felix Miata <mrmazda@earthlink.net> - 2019-03-01 19:30 +0100
          Re: User rw Permissions on New Hard Drive David Wright <deblis@lionunicorn.co.uk> - 2019-03-01 18:00 +0100
            Re: User rw Permissions on New Hard Drive Greg Wooledge <wooledg@eeg.ccf.org> - 2019-03-01 18:10 +0100
              Re: User rw Permissions on New Hard Drive David Wright <deblis@lionunicorn.co.uk> - 2019-03-01 18:40 +0100
      Re: User rw Permissions on New Hard Drive Dekks Herton <dekkzz78@gmail.com> - 2019-03-01 08:40 +0100
        Re: User rw Permissions on New Hard Drive Michael Stone <mstone@debian.org> - 2019-03-01 15:40 +0100
          Re: User rw Permissions on New Hard Drive Stefan Monnier <monnier@iro.umontreal.ca> - 2019-03-01 18:50 +0100
            Re: User rw Permissions on New Hard Drive Reco <recoverym4n@enotuniq.net> - 2019-03-01 19:10 +0100
        Re: User rw Permissions on New Hard Drive David Wright <deblis@lionunicorn.co.uk> - 2019-03-01 18:20 +0100
      Re: User rw Permissions on New Hard Drive "Stephen P. Molnar" <s.molnar@sbcglobal.net> - 2019-03-05 15:20 +0100
        Re: User rw Permissions on New Hard Drive Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-03-05 20:20 +0100
        Re: User rw Permissions on New Hard Drive "Stephen P. Molnar" <s.molnar@sbcglobal.net> - 2019-03-06 23:50 +0100
    Re: User rw Permissions on New Hard Drive Cousin Stanley <cousinstanley@gmail.com> - 2019-03-07 15:40 +0100
      Re: User rw Permissions on New Hard Drive Michael Stone <mstone@debian.org> - 2019-03-07 16:10 +0100
        Re: User rw Permissions on New Hard Drive Cousin Stanley <cousinstanley@gmail.com> - 2019-03-07 18:20 +0100
          Re: User rw Permissions on New Hard Drive Michael Stone <mstone@debian.org> - 2019-03-07 19:10 +0100
          Re: User rw Permissions on New Hard Drive David Wright <deblis@lionunicorn.co.uk> - 2019-03-07 20:30 +0100
            Re: User rw Permissions on New Hard Drive Cousin Stanley <cousinstanley@gmail.com> - 2019-03-07 22:10 +0100
              Re: User rw Permissions on New Hard Drive Michael Stone <mstone@debian.org> - 2019-03-07 22:30 +0100
                Re: User rw Permissions on New Hard Drive Cousin Stanley <cousinstanley@gmail.com> - 2019-03-08 01:30 +0100
              Re: User rw Permissions on New Hard Drive David Wright <deblis@lionunicorn.co.uk> - 2019-03-08 03:20 +0100
                Re: User rw Permissions on New Hard Drive Cousin Stanley <cousinstanley@gmail.com> - 2019-03-08 07:10 +0100
            Re: User rw Permissions on New Hard Drive Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-03-07 23:20 +0100
              Re: User rw Permissions on New Hard Drive David Wright <deblis@lionunicorn.co.uk> - 2019-03-08 04:20 +0100
                Re: User rw Permissions on New Hard Drive Greg Wooledge <wooledg@eeg.ccf.org> - 2019-03-08 14:30 +0100
                  Re: User rw Permissions on New Hard Drive David Wright <deblis@lionunicorn.co.uk> - 2019-03-09 05:30 +0100
                Re: User rw Permissions on New Hard Drive Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-03-09 20:40 +0100
                  Re: User rw Permissions on New Hard Drive David Wright <deblis@lionunicorn.co.uk> - 2019-03-11 19:50 +0100
                    Re: User rw Permissions on New Hard Drive Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-03-16 10:50 +0100
                      Re: User rw Permissions on New Hard Drive David Wright <deblis@lionunicorn.co.uk> - 2019-03-17 16:30 +0100
      Re: User rw Permissions on New Hard Drive Felix Miata <mrmazda@earthlink.net> - 2019-03-07 18:20 +0100

Page 2 of 2 — ← Prev page 1 [2]

#206049

On Thu, Mar 07, 2019 at 07:11:36AM -0700, Cousin Stanley wrote:
>Stephen P. Molnar wrote:
>
>> ....
>> and my fstab is:
>>
>> # /etc/fstab: static file system information.
>> ....
>
>  I've found that labeling my disk partitions
>  and using  /dev/disk/by-label/xyzzy  lines
>  in the  /etc/fstab  file seems to be much easier
>  for my own small brain to comprehend.

If you want to use labels, it seems a lot more clear to use LABEL= 
rather than /dev/disk/by-label/

[toc] | [prev] | [next] | [standalone]

#206051

Michael Stone wrote:

> On Thu, Mar 07, 2019 at 07:11:36AM -0700, Cousin Stanley wrote:
>>Stephen P. Molnar wrote:
>>
>>> ....
>>> and my fstab is:
>>>
>>> # /etc/fstab: static file system information.
>>> ....
>>
>>  I've found that labeling my disk partitions
>>  and using  /dev/disk/by-label/xyzzy  lines
>>  in the  /etc/fstab  file seems to be much easier
>>  for my own small brain to comprehend.
> 
> If you want to use labels, it seems a lot more clear 
> to use  LABEL=  rather than /dev/disk/by-label/

  I am aware of the  LABEL=  keyword for the disk labels
  in the  /etc/fstab  file and would agree that
  their use would be slightly more concise
  and save a few key strokes.

  However, in my own mind not necessarily more clear
  as  /dev/disk/by-label  shows me exactly
  what sort of label is being referenced
  and provides a reminder that I can check them
  via  ls -Ahl /dev/disk/by-label .

  Taking a line from Tim Peters' Zen of Python ....

    Explicit is better than implicit


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

[toc] | [prev] | [next] | [standalone]

#206053

On Thu, Mar 07, 2019 at 09:59:43AM -0700, Cousin Stanley wrote:
>Michael Stone wrote:
>> On Thu, Mar 07, 2019 at 07:11:36AM -0700, Cousin Stanley wrote:
>>>Stephen P. Molnar wrote:
>>>
>>>> ....
>>>> and my fstab is:
>>>>
>>>> # /etc/fstab: static file system information.
>>>> ....
>>>
>>>  I've found that labeling my disk partitions
>>>  and using  /dev/disk/by-label/xyzzy  lines
>>>  in the  /etc/fstab  file seems to be much easier
>>>  for my own small brain to comprehend.
>>
>> If you want to use labels, it seems a lot more clear
>> to use  LABEL=  rather than /dev/disk/by-label/
>
>  I am aware of the  LABEL=  keyword for the disk labels
>  in the  /etc/fstab  file and would agree that
>  their use would be slightly more concise
>  and save a few key strokes.
>
>  However, in my own mind not necessarily more clear
>  as  /dev/disk/by-label  shows me exactly
>  what sort of label is being referenced
>  and provides a reminder that I can check them
>  via  ls -Ahl /dev/disk/by-label .

Well, if you checked them using blkid, they'd say "LABEL=", so this 
seems somewhat circular. :) 

[toc] | [prev] | [next] | [standalone]

#206054

On Thu 07 Mar 2019 at 09:59:43 (-0700), Cousin Stanley wrote:
> Michael Stone wrote:
> > On Thu, Mar 07, 2019 at 07:11:36AM -0700, Cousin Stanley wrote:
> >>Stephen P. Molnar wrote:
> >>> ....
> >>> and my fstab is:
> >>>
> >>> # /etc/fstab: static file system information.
> >>> ....
> >>
> >>  I've found that labeling my disk partitions
> >>  and using  /dev/disk/by-label/xyzzy  lines
> >>  in the  /etc/fstab  file seems to be much easier
> >>  for my own small brain to comprehend.
> > 
> > If you want to use labels, it seems a lot more clear 
> > to use  LABEL=  rather than /dev/disk/by-label/
> 
>   I am aware of the  LABEL=  keyword for the disk labels
>   in the  /etc/fstab  file and would agree that
>   their use would be slightly more concise
>   and save a few key strokes.
> 
>   However, in my own mind not necessarily more clear
>   as  /dev/disk/by-label  shows me exactly
>   what sort of label is being referenced
>   and provides a reminder that I can check them
>   via  ls -Ahl /dev/disk/by-label .
> 
>   Taking a line from Tim Peters' Zen of Python ....
> 
>     Explicit is better than implicit

I prefer to populate fstab with canonical information that actually
belongs to the filesystems that are to be mounted. A filesystem
that has a label, has that label regardless of any OS. It's real,
defined in the filesystem's documentation.

All that stuff in /dev/disk/ is just an ephemeral bunch of
convenient symbolic links, presumably conjured up by udev or
somesuch, if not the linux kernel.

I'm not clear about which other sort of label might be referenced
by LABEL=.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#206055

David Wright wrote:

> I prefer to populate fstab with canonical information 
> that actually belongs to the filesystems that are to be mounted. 

  I don't understand what you're saying here.

  Does a disk label not belong to a filesystem
  that is to be mounted ?

> A filesystem  that has a label, 
> has that label regardless of any OS. 
>
> It's real, defined in the filesystem's documentation.
>
> All that stuff in /dev/disk/ is just an ephemeral 
> bunch of convenient symbolic links, presumably conjured 
> up by udev or somesuch, if not the linux kernel

  But are they not accurate after boot
  for particular disks on a particular machine ?

> I'm not clear about which other sort of label
> might be referenced by LABEL=

  I'm not either but if I use /dev/disk/by-label
  I  think  I know what sort  that  is .... :)


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

[toc] | [prev] | [next] | [standalone]

#206056

On Thu, Mar 07, 2019 at 01:49:42PM -0700, Cousin Stanley wrote:
>David Wright wrote:
>> All that stuff in /dev/disk/ is just an ephemeral
>> bunch of convenient symbolic links, presumably conjured
>> up by udev or somesuch, if not the linux kernel
>
>  But are they not accurate after boot
>  for particular disks on a particular machine ?

Maybe. The LABEL= is parsed by mount, which uses the same logic/source 
for that as blkid. The /dev/disk stuff is actually the product of more 
indirection and another codebase--more likely to break than LABEL=. (Not 
that either is likely. So shortest is best. :D)

[toc] | [prev] | [next] | [standalone]

#206060

Michael Stone wrote:

> On Thu, Mar 07, 2019 at 01:49:42PM -0700, Cousin Stanley wrote:
>>David Wright wrote:
>>> All that stuff in /dev/disk/ is just an ephemeral
>>> bunch of convenient symbolic links, presumably conjured
>>> up by udev or somesuch, if not the linux kernel
>>
>>  But are they not accurate after boot
>>  for particular disks on a particular machine ?
> 
>
> Maybe. 
> 
> The LABEL= is parsed by mount, which uses the same logic/source
> for that as blkid. 
> 
> The /dev/disk stuff is actually the product of more indirection 
> and another codebase--morelikely to break than LABEL=. 
> 
> (Not that either is likely. 
> 
> So shortest is best. :D)

  OK, I can understand a higher potential for breakage
  due to a different codebase and/or indirection .... 

  I suppose I've been lucky to never have encountered
  any problems using  /dev/disk/by-label  in fstab
  but I've only ever run machines with at most 
  2 drives along with an optical drive .... 

  I have swapped drives between machines a few times
  for one reason or another, but don't recall
  any problems with those either after fstab adjustments.


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

[toc] | [prev] | [next] | [standalone]

#206062

On Thu 07 Mar 2019 at 13:49:42 (-0700), Cousin Stanley wrote:
> David Wright wrote:
> 
> > I prefer to populate fstab with canonical information 
> > that actually belongs to the filesystems that are to be mounted. 
> 
>   I don't understand what you're saying here.
> 
>   Does a disk label not belong to a filesystem
>   that is to be mounted ?

Yes. Using a concrete example from /etc/fstab, in:

LABEL=sand1g /media/camera1g vfat rw,errors=remount-ro,utf8,tz=UTC,shortname=lower,user,noauto,fmask=137,dmask=027

the characters sand1g have been written in the partition on the
device, an SD card. (The fact that they're lowercase means that
it's unlikely I wrote that LABEL in DOS or Windows.) But were
I to have put in /etc/fstab:

/dev/disk/by-label/sand1g /media/camera1g vfat rw,errors=remount-ro,utf8,tz=UTC,shortname=lower,user,noauto,fmask=137,dmask=027

I would not expect to find the characters /dev/disk/by-label/ anywhere
in the partition. That string belongs to the linux system, not to
the card. That's what I meant by "actually belongs to the filesystems".

> > A filesystem  that has a label, 
> > has that label regardless of any OS. 
> >
> > It's real, defined in the filesystem's documentation.
> >
> > All that stuff in /dev/disk/ is just an ephemeral 
> > bunch of convenient symbolic links, presumably conjured 
> > up by udev or somesuch, if not the linux kernel
> 
>   But are they not accurate after boot
>   for particular disks on a particular machine ?

I don't question its accuracy.

> > I'm not clear about which other sort of label
> > might be referenced by LABEL=
> 
>   I'm not either but if I use /dev/disk/by-label
>   I  think  I know what sort  that  is .... :)

OK, I thought you had something in mind.

BTW, in looking at   man mount   (to remind myself of the -L option),
I noticed that it actually mentions this business:

   "The recommended setup is to use tags (e.g. LABEL=label) rather
   than /dev/disk/by-{label,uuid,partuuid,partlabel} udev symlinks in
   the /etc/fstab file. Tags are more readable, robust and portable."

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#206064

David Wright wrote:

> I would not expect to find the characters 
> /dev/disk/by-label/ anywhere in the partition. 
> 
> That string belongs to the linux system, not to the card. 
> 
> That's what I meant by "actually belongs to the filesystems".

  OK, that's clear and I understand.

>> I'm not clear about which other sort of label
>> might be referenced by LABEL=
> 
>   I'm not either but if I use /dev/disk/by-label
>   I  think  I know what sort  that  is .... :)
>
>  OK, I thought you had something in mind

  Actually, I was thinking about the slot for partition name
  that shows up in gparted as a possible source of confusion,
  at least to me.

  I've always left that one blank when partitioning
  with gparted and used the plain vanilla  label  slot.

> BTW, in looking at   man mount   (to remind myself of the -L option),
> I noticed that it actually mentions this business:
>
>   "The recommended setup is to use tags (e.g. LABEL=label) rather
>    than /dev/disk/by-{label,uuid,partuuid,partlabel} udev symlinks 
>    in the /etc/fstab file. 
>
 
  It's been so long since I've checked man mount  
  that I've completely missed this recommendation.

> Tags are more readable, robust and portable."

  I would agree after the informative discussions here
  that the  LABEL=  tags in fstab are probably more
  robust and portable.

  But my feeble mind still believes /dev/disk/by-label
  is more readable to me personally as it just 
  seems more explicit ....  :-)
  

-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

[toc] | [prev] | [next] | [standalone]

#206057

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 ? It has a set of identifiers, and I observed 
that Windows and blkid did not use the same identifier as the label.

[toc] | [prev] | [next] | [standalone]

#206063

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.

/dev/disk/by-id:
lrwxrwxrwx 1 root root  9 Mar  7 19:31 usb-HL-DT-ST_DVDRAM_SP60NB50_KZ5E19K3606-0:0 -> ../../sr0
/dev/disk/by-label:
lrwxrwxrwx 1 root root  9 Mar  7 19:31 DVD_VR -> ../../sr0
/dev/disk/by-path:
lrwxrwxrwx 1 root root  9 Mar  7 19:31 pci-0000:00:14.0-usb-0:2:1.0-scsi-0:0:0:0 -> ../../sr0
/dev/disk/by-uuid:
lrwxrwxrwx 1 root root  9 Mar  7 19:31 2055-06-04-17-19-32-00 -> ../../sr0

# mount /dev/sr0 /mnt
mount: /dev/sr0 is write-protected, mounting read-only
# umount /mnt
# mount -L DVD_VR /mnt
mount: /dev/sr0 is write-protected, mounting read-only
# blkid -L DVD_VR
/dev/sr0
# blkid -U 2055-06-04-17-19-32-00
/dev/sr0
# 

$ lsblk -f
NAME         FSTYPE      LABEL       UUID                                 MOUNTPOINT
[…]
sr0          udf         DVD_VR      2055-06-04-17-19-32-00               /mnt
$ 

> 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.
I wouldn't know how Windows mounts/unmounts them. I think DOS used
to display the UUIDs, but it's been a long time … (Did I ever feed
a DVD to DOS? Probably not.)

The LABELs on these DVDs are not particularly useful as they were
written, I assume, by the DVD recorder that burned them, and they're
all the same. The UUIDs vary, but the identification I actually use
is what I wrote on them with a pen. Distinguishing them when inside
the drive hasn't seemed particularly important.

I have a few "bought" DVDs, but like most people, I suspect, I just
look at the box and physical labels to see what's on them. I'm told
that some people examine the markings on them to see where they were
manufactured, … but now I'm rambling.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#206071

On Thu, Mar 07, 2019 at 09:15:51PM -0600, David Wright wrote:
> 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.

For writing, fstab and mount are not involved in any way whatsoever.
The device must *not* be mounted, and one must ensure that no Desktop
Environment application will attempt to auto-mount the medium while the
write is underway.

After generating or downloading the image, one simply uses a command like

cdrecord -v image.iso

or the equivalent command for other software.  On a machine with just one
CD/DVD drive, you typically don't even need to specify the device.

[toc] | [prev] | [next] | [standalone]

#206073

Please don't oversnip. This subthread was about labels (aka LABELs).

On Fri 08 Mar 2019 at 08:20:40 (-0500), Greg Wooledge wrote:
> On Thu, Mar 07, 2019 at 09:15:51PM -0600, David Wright wrote:
> > 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.
> 
> For writing, fstab and mount are not involved in any way whatsoever.
> The device must *not* be mounted, and one must ensure that no Desktop
> Environment application will attempt to auto-mount the medium while the
> write is underway.
> 
> After generating or downloading the image,

That was my point. In order to generate an image like the ones
illustrated, which were from DVDs burned in my DVD recorder from
analogue input, I would have to know how to write a UDF filesystem.
So my answering "Yes" to "Have you ever used UDF ?" needed qualification.

In case you missed the point, the symlinks, mount and blkid commands
were included in the post only to demonstrate that the LABELs I was
observing in the UDF filesystems on my DVDs were usable in the same
way as those in extX and FAT filesystems. (If it walks like a duck …)

> > > It has a set of identifiers, and I observed
> > > that Windows and blkid did not use the same identifier as the label.

If I *had* experience of writing DVDs, then I might have known what
the set of identifiers were that Pascal was speaking about. As it is,
I guessed there'd be a mkudffs command, and googling its man page
revealed that there may be about four LABELish thingies. (I don't know
which might be quacking like a duck on my DVDs.) Perhaps I'll take a
look at these items some other time.

> one simply uses a command like
> 
> cdrecord -v image.iso
> 
> or the equivalent command for other software.  On a machine with just one
> CD/DVD drive, you typically don't even need to specify the device.

I've only burned CDs, and they've typically had iso9660 filesystems,
or else no filesystems at all (ie Red Book). The former have LABELs
which I set with mkisofs -V <LABEL>.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#206085

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.

>> 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. I just 
gave an example of a filesystem for which two different OSes use two 
different identifiers as the label.

[toc] | [prev] | [next] | [standalone]

#206164

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.

[toc] | [prev] | [next] | [standalone]

#206273

Le 11/03/2019 à 19:46, David Wright a écrit :
> On Sat 09 Mar 2019 at 20:31:36 (+0100), Pascal Hambourg wrote:
>>
>> 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.

No, the "U" stands for "Universal" and its is designed for a broad range 
of media, including hard disks. It just has special features for optical 
media, but is not restricted to them.

The format.exe utility in Windows has an option to format a drive or 
partition with UDF, so this is really not an oddity.

> I might be
> happier if it were integrated into the kernel rather than just a
> user application.

What do you mean ? The UDF driver is integrated in the kernel (unlike 
NTFS which requires a FUSE driver to enable full-featured writes). Not 
to be confused with CD/DVD authoring software which have a different 
purpose.

>> 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 understand what you mean, but my point is that it does not make any 
difference in practice. Whatever intrinsic metadata is stored on the 
device is irrelevant ; what actually matters is what metadata the 
operating system uses as a label. If different operating systems use 
different metadata as the label, then you cannot consider that the label 
is independent of any operating systems.

[toc] | [prev] | [next] | [standalone]

#206285

On Sat 16 Mar 2019 at 10:49:19 (+0100), Pascal Hambourg wrote:
> Le 11/03/2019 à 19:46, David Wright a écrit :
> > On Sat 09 Mar 2019 at 20:31:36 (+0100), Pascal Hambourg wrote:
> > > 
> > > 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.
> 
> No, the "U" stands for "Universal" and its is designed for a broad
> range of media, including hard disks. It just has special features for
> optical media, but is not restricted to them.
> 
> The format.exe utility in Windows has an option to format a drive or
> partition with UDF, so this is really not an oddity.
> 
> > I might be
> > happier if it were integrated into the kernel rather than just a
> > user application.
> 
> What do you mean ? The UDF driver is integrated in the kernel (unlike
> NTFS which requires a FUSE driver to enable full-featured writes). Not
> to be confused with CD/DVD authoring software which have a different
> purpose.

You're right: I hadn't appreciated that the udf module only gets
loaded when you mount a UDF filesystem. It doesn't appear to be
needed for reading the LABEL/UUID when a device is connected, so
it remains absent from /proc/filesystems for example.

But I *was* briefly caught out by the necessity of blanking the
first MB of the device/partition before running mkudffs, which
didn't help matters. (Reminds me of fighting with DOS over
partition information.)

Having read a little and experimented a little, I think I'll leave
this format alone at least for a while.

For USB sticks (and SD cards): sure, they might work with Windows and
linux, but that's about it. They don't work in the car, nor in any of
our TVs, nor cameras/phones.

For spinning rust: I've read about erroneous 'space full' messages
on large partitions, and the ongoing lack of any fsck tool. That
could be a big problem with TB disks.

> > > 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 understand what you mean, but my point is that it does not make any
> difference in practice.

We know that: Cousin Stanley's disks mount successfully and so do
Michael Stone's and mine.

> Whatever intrinsic metadata is stored on the
> device is irrelevant ; what actually matters is what metadata the
> operating system uses as a label. If different operating systems use
> different metadata as the label, then you cannot consider that the
> label is independent of any operating systems.

If an OS foo decides to use metadata bar as the "label" for a given
device, then the information "bar" must appear on the device (or else
"label" is being used in a metaphorical sense like in politics). All
you've demonstrated in your example is that there might be more than
one label, suiting different circumstances.

In writing mkudffs, it appears that the authors have allowed easy
avoidance of that problem by supplying an argument that sets both
labels (here called identifiers) to the same string. A result is
that linux (I haven't checked with Windows) will read that string
as the value for LABEL.

Going back to Cousin Stanley's point, the LABEL's value is bar,
and I expressed the view that fstab's field 1 being set to
"LABEL=bar" is more explicit than "/dev/disk/by-label/bar".

If the "metadata the operating system uses as a label" bears no
relation to the "intrinsic metadata is stored on the device" (for
example, it might count the number of discs ever inserted into
a reader, and use that number as the label), then I think the
OS's designers might have difficulty justifying their decision.

(If that example appears a stretch, it's because I'm having difficulty
thinking of an example where a label isn't intended to be in or on
something. Perhaps when it's been deliberately unpeeled or chiselled?)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#206052

Cousin Stanley composed on 2019-03-07 07:11 (UTC-0700):

>   To label the disk partitions check the  man  pages
>   for the following labeling options ....
> 
>    $ ls -1 /sbin | grep label
>    dosfslabel
>    e2label
>    exfatlabel
>    fatlabel
>    ntfslabel
>    swaplabel

>   The  e2label  program is effective for  ext  partitions.

That list leaves out tune2fs, which can not only change label, but also UUID, which typically needs
changing at the same time when cloning is involved.

>   To list the disk labels .... 

>   $ ls -Ahl /dev/disk/by-label

blkid works too.

Plus: as Michael Stone wrote: LABEL=, both in fstab and grub.cfg.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web