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

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

Distinguishing among [unmount, Safely Remove Drive, Eject]

Started byRichard Owlett <rowlett@cloud85.net>
First post2018-05-05 18:10 +0200
Last post2018-05-09 20:40 +0200
Articles 14 on this page of 34 — 13 participants

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

Contents

  Distinguishing among [unmount, Safely Remove Drive, Eject] Richard Owlett <rowlett@cloud85.net> - 2018-05-05 18:10 +0200
    Re: Distinguishing among [unmount, Safely Remove Drive, Eject] "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-05 19:10 +0200
      Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Reco <recoverym4n@gmail.com> - 2018-05-05 20:00 +0200
        Re: Distinguishing among [unmount, Safely Remove Drive, Eject] "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-05 20:50 +0200
          Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Reco <recoverym4n@gmail.com> - 2018-05-05 21:00 +0200
    Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Brad Rogers <brad@fineby.me.uk> - 2018-05-05 19:20 +0200
      Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Reco <recoverym4n@gmail.com> - 2018-05-05 20:10 +0200
        Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Felix Dietrich <felix.dietrich@sperrhaken.name> - 2018-05-06 10:40 +0200
          Re: Distinguishing among [unmount, Safely Remove Drive, Eject] songbird <songbird@anthive.com> - 2018-05-06 13:00 +0200
          Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Reco <recoverym4n@gmail.com> - 2018-05-06 13:20 +0200
            Re: Distinguishing among [unmount, Safely Remove Drive, Eject] rhkramer@gmail.com - 2018-05-06 14:00 +0200
              Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Reco <recoverym4n@gmail.com> - 2018-05-06 14:20 +0200
                Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Charlie S <taoquester@gmail.com> - 2018-05-06 14:40 +0200
                  Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Reco <recoverym4n@gmail.com> - 2018-05-06 15:10 +0200
                Re: Distinguishing among [unmount, Safely Remove Drive, Eject] rhkramer@gmail.com - 2018-05-06 15:10 +0200
                  Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Reco <recoverym4n@gmail.com> - 2018-05-06 15:40 +0200
                    Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Richard Owlett <rowlett@cloud85.net> - 2018-05-06 16:10 +0200
                      Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Reco <recoverym4n@gmail.com> - 2018-05-06 16:20 +0200
                        Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Richard Owlett <rowlett@cloud85.net> - 2018-05-06 16:40 +0200
              Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Richard Owlett <rowlett@cloud85.net> - 2018-05-06 15:00 +0200
    Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-05 21:00 +0200
    Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Brian <ad44@cityscape.co.uk> - 2018-05-05 21:40 +0200
      Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Richard Hector <richard@walnut.gen.nz> - 2018-05-06 06:00 +0200
        Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Brian <ad44@cityscape.co.uk> - 2018-05-06 16:30 +0200
          Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Richard Owlett <rowlett@cloud85.net> - 2018-05-06 16:50 +0200
            Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Richard Owlett <rowlett@cloud85.net> - 2018-05-09 20:00 +0200
              Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Brian <ad44@cityscape.co.uk> - 2018-05-09 20:40 +0200
                Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Liam O'Toole <liam.p.otoole@gmail.com> - 2018-05-10 00:00 +0200
    Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Henrique de Moraes Holschuh <hmh@debian.org> - 2018-05-06 13:30 +0200
      Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Richard Owlett <rowlett@cloud85.net> - 2018-05-06 14:30 +0200
        Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Henrique de Moraes Holschuh <hmh@debian.org> - 2018-05-06 23:00 +0200
        Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Brian <ad44@cityscape.co.uk> - 2018-05-08 21:10 +0200
          Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Richard Owlett <rowlett@cloud85.net> - 2018-05-09 20:10 +0200
            Re: Distinguishing among [unmount, Safely Remove Drive, Eject] Brian <ad44@cityscape.co.uk> - 2018-05-09 20:40 +0200

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

#195306

FromAbdullah Ramazanoğlu <ar018@yahoo.com>
Date2018-05-05 21:00 +0200
Message-ID<vMazv-Cn-1@gated-at.bofh.it>
In reply to#195299
On Sat, 5 May 2018 11:06:25 -0500 Richard Owlett said:

> What are the distinguishing features of unmount, Safely Remove Drive, 
> and Eject?

"Unmount" is the head operation of all, which flushes all pending
(cached/buffered) writes to the media, and detaches it from the filesystem
tree. As for R/O media, it just detaches it from the filesystem. After unmount,
you have a *logically* detached, separate media, standing alone by itself in
your system. It is *physically* attached, though. An unmounted device becomes
inaccesible from filesystem hierarchy (though accessible as a raw partition or
device), immune to power loss, immune to user or system bugs.

"Safely Remove" is a coined term for easily detachable R/W media, meaning
"unmount it, so that it can be manually detached". In some implementations, it
can also attempt to mechanically eject the device if possible (DVD for
instance).

"Eject" simply means mechanically eject an ejectable media (DVD). In its
earliest form, it would blindly attempt to eject a mounted CD and fail, because
mount operation locks the mechanism so it cannot be ejected prior to
unmounting. Later versions of "eject" is smart enough to first unmount and then
do its main job (mechanical ejection of media).

Regards
-- 
Abdullah Ramazanoğlu

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

#195308

FromBrian <ad44@cityscape.co.uk>
Date2018-05-05 21:40 +0200
Message-ID<vMbce-1em-1@gated-at.bofh.it>
In reply to#195299
On Sat 05 May 2018 at 11:06:25 -0500, Richard Owlett wrote:

> What are the distinguishing features of unmount, Safely Remove Drive, and
> Eject?

There are none. The device is either unmounted or it isn't. It cannnot
be half-unmounted.

-- 
Brian.

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

#195318

FromRichard Hector <richard@walnut.gen.nz>
Date2018-05-06 06:00 +0200
Message-ID<vMj05-6fg-3@gated-at.bofh.it>
In reply to#195308

[Multipart message — attachments visible in raw view] — view raw

On 06/05/18 07:35, Brian wrote:
> On Sat 05 May 2018 at 11:06:25 -0500, Richard Owlett wrote:
> 
>> What are the distinguishing features of unmount, Safely Remove Drive, and
>> Eject?
> 
> There are none. The device is either unmounted or it isn't. It cannnot
> be half-unmounted.

Hmm. Is there not a point where it's been made inaccessible to the
filesystem, but caches are not yet flushed?

Richard

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

#195340

FromBrian <ad44@cityscape.co.uk>
Date2018-05-06 16:30 +0200
Message-ID<vMsPM-4uD-17@gated-at.bofh.it>
In reply to#195318
On Sun 06 May 2018 at 15:53:05 +1200, Richard Hector wrote:

> On 06/05/18 07:35, Brian wrote:
> > On Sat 05 May 2018 at 11:06:25 -0500, Richard Owlett wrote:
> > 
> >> What are the distinguishing features of unmount, Safely Remove Drive, and
> >> Eject?
> > 
> > There are none. The device is either unmounted or it isn't. It cannnot
> > be half-unmounted.
> 
> Hmm. Is there not a point where it's been made inaccessible to the
> filesystem, but caches are not yet flushed?

I don't know but I've always thought that unmounting a USB stick led to
a sync action and buffers were flushed. Anyway, in the light of Henrique
de Moraes Holschuh's enlightening post I'll back away a little from my
previous mail and give a restructured response.

Although it is from a few years ago, the material at

  https://bugzilla.gnome.org/show_bug.cgi?id=598690

could still be useful. Safely Remove Drive and Eject are associated
with DEs, although Xfce seems to manage without them and has unmount as
an only option.

udisks2 is the software involved. A test (as an unprivileged user) after
plugging in a USB stick:

 lsblk                            (To get the device)
 udisksctl mount -b /dev/sdg1
 udisksctl unmount -b /dev/sdg1   (Must be done before the next command).
 udisksctl power-off -b /dev/sdg1 (Observe indicator light on the stick).

The stick needs detaching and re-inserting to get mounting to work again.

>From udisksctl(1):

 power-off
  Arranges for the drive to be safely removed and powered off. On the
  OS side this includes ensuring that no process is using the drive,
  then requesting that in-flight buffers and caches are committed to
  stable storage. The exact steps for powering off the drive depends
  on the drive itself and the interconnect used. For drives connected
  through USB, the effect is that the USB device will be deconfigured
  followed by disabling the upstream hub port it is connected to.
 
  Note that as some physical devices contain multiple drives (for
  example 4-in-1 flash card reader USB devices) powering off one drive
  may affect other drives. As such there are not a lot of guarantees
  associated with performing this action. Usually the effect is that
  the drive disappears as if it was unplugged.

I'm still pondering why I would need power-off with a USB device.

-- 
Brian.

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

#195345

FromRichard Owlett <rowlett@cloud85.net>
Date2018-05-06 16:50 +0200
Message-ID<vMt98-4Bc-9@gated-at.bofh.it>
In reply to#195340
On 05/06/2018 09:26 AM, Brian wrote:
> On Sun 06 May 2018 at 15:53:05 +1200, Richard Hector wrote:
> 
>> On 06/05/18 07:35, Brian wrote:
>>> On Sat 05 May 2018 at 11:06:25 -0500, Richard Owlett wrote:
>>>
>>>> What are the distinguishing features of unmount, Safely Remove Drive, and
>>>> Eject?
>>>
>>> There are none. The device is either unmounted or it isn't. It cannnot
>>> be half-unmounted.
>>
>> Hmm. Is there not a point where it's been made inaccessible to the
>> filesystem, but caches are not yet flushed?
> 
> I don't know but I've always thought that unmounting a USB stick led to
> a sync action and buffers were flushed. Anyway, in the light of Henrique
> de Moraes Holschuh's enlightening post I'll back away a little from my
> previous mail and give a restructured response.
> 
> Although it is from a few years ago, the material at
> 
>    https://bugzilla.gnome.org/show_bug.cgi?id=598690
> 
> could still be useful. Safely Remove Drive and Eject are associated
> with DEs, although Xfce seems to manage without them and has unmount as
> an only option.
> 
> udisks2 is the software involved. A test (as an unprivileged user) after
> plugging in a USB stick:
> 
>   lsblk                            (To get the device)
>   udisksctl mount -b /dev/sdg1
>   udisksctl unmount -b /dev/sdg1   (Must be done before the next command).
>   udisksctl power-off -b /dev/sdg1 (Observe indicator light on the stick).
> 
> The stick needs detaching and re-inserting to get mounting to work again.
> 
>>From udisksctl(1):
> 
>   power-off
>    Arranges for the drive to be safely removed and powered off. On the
>    OS side this includes ensuring that no process is using the drive,
>    then requesting that in-flight buffers and caches are committed to
>    stable storage. The exact steps for powering off the drive depends
>    on the drive itself and the interconnect used. For drives connected
>    through USB, the effect is that the USB device will be deconfigured
>    followed by disabling the upstream hub port it is connected to.
>   
>    Note that as some physical devices contain multiple drives (for
>    example 4-in-1 flash card reader USB devices) powering off one drive
>    may affect other drives. As such there are not a lot of guarantees
>    associated with performing this action. Usually the effect is that
>    the drive disappears as if it was unplugged.
> 
> I'm still pondering why I would need power-off with a USB device.
> 

That explains a lot. Will have to wait till this afternoon to read your 
reference.

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

#195535

FromRichard Owlett <rowlett@cloud85.net>
Date2018-05-09 20:00 +0200
Message-ID<vNBxD-6A0-1@gated-at.bofh.it>
In reply to#195345
On 05/06/2018 09:42 AM, Richard Owlett wrote:
> On 05/06/2018 09:26 AM, Brian wrote:
>> On Sun 06 May 2018 at 15:53:05 +1200, Richard Hector wrote:
>>
>>> On 06/05/18 07:35, Brian wrote:
>>>> On Sat 05 May 2018 at 11:06:25 -0500, Richard Owlett wrote:
>>>>
>>>>> What are the distinguishing features of unmount, Safely Remove 
>>>>> Drive, and
>>>>> Eject?
>>>>

[*SNIP*]

>>
>> Although it is from a few years ago, the material at
>>
>>    https://bugzilla.gnome.org/show_bug.cgi?id=598690
>>
>> could still be useful. Safely Remove Drive and Eject are associated
>> with DEs, although Xfce seems to manage without them and has unmount as
>> an only option.

Just got a chance to look at it, has points in common with my problem.
It, and related bugs, will be worth a detailed read.
I'm suspecting that there were explicit choices made that I wouldn't.
Or, to paraphrase a truism, "You can satisfy some of the people all of 
the time, and all of the people some of the time, but you can not 
satisfy all of the people all of the time."

>>[snip]
> That explains a lot. Will have to wait till this afternoon to read your 
> reference.

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

#195537

FromBrian <ad44@cityscape.co.uk>
Date2018-05-09 20:40 +0200
Message-ID<vNCaq-735-5@gated-at.bofh.it>
In reply to#195535
On Wed 09 May 2018 at 12:50:29 -0500, Richard Owlett wrote:

> On 05/06/2018 09:42 AM, Richard Owlett wrote:
> > On 05/06/2018 09:26 AM, Brian wrote:
> > > On Sun 06 May 2018 at 15:53:05 +1200, Richard Hector wrote:
> > > 
> > > > On 06/05/18 07:35, Brian wrote:
> > > > > On Sat 05 May 2018 at 11:06:25 -0500, Richard Owlett wrote:
> > > > > 
> > > > > > What are the distinguishing features of unmount, Safely
> > > > > > Remove Drive, and
> > > > > > Eject?
> > > > > 
> 
> [*SNIP*]
> 
> > > 
> > > Although it is from a few years ago, the material at
> > > 
> > >    https://bugzilla.gnome.org/show_bug.cgi?id=598690
> > > 
> > > could still be useful. Safely Remove Drive and Eject are associated
> > > with DEs, although Xfce seems to manage without them and has unmount as
> > > an only option.
> 
> Just got a chance to look at it, has points in common with my problem.
> It, and related bugs, will be worth a detailed read.

You have *never* explained what *your* problem is. Whatever *you* read
will not make it any clearer to us what the issue is. It is what *we*
read which determines what we have to respond to. Could you not be more
helpful and forthcoming?

> I'm suspecting that there were explicit choices made that I wouldn't.

You can suspect what you like. We would like to know exactly what it
is that is exercising you.

> Or, to paraphrase a truism, "You can satisfy some of the people all of the
> time, and all of the people some of the time, but you can not satisfy all of
> the people all of the time."

Gosh, I wish I had said that!

-- 
Brian.

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

#195543

FromLiam O'Toole <liam.p.otoole@gmail.com>
Date2018-05-10 00:00 +0200
Message-ID<vNFhU-pf-7@gated-at.bofh.it>
In reply to#195537
On 2018-05-09, Brian <ad44@cityscape.co.uk> wrote:
> On Wed 09 May 2018 at 12:50:29 -0500, Richard Owlett wrote:
>
>> On 05/06/2018 09:42 AM, Richard Owlett wrote:
>> > On 05/06/2018 09:26 AM, Brian wrote:
>> > > On Sun 06 May 2018 at 15:53:05 +1200, Richard Hector wrote:
>> > > 
>> > > > On 06/05/18 07:35, Brian wrote:
>> > > > > On Sat 05 May 2018 at 11:06:25 -0500, Richard Owlett wrote:
>> > > > > 
>> > > > > > What are the distinguishing features of unmount, Safely
>> > > > > > Remove Drive, and
>> > > > > > Eject?
>> > > > > 
>> 
>> [*SNIP*]
>> 
>> > > 
>> > > Although it is from a few years ago, the material at
>> > > 
>> > >    https://bugzilla.gnome.org/show_bug.cgi?id=598690
>> > > 
>> > > could still be useful. Safely Remove Drive and Eject are associated
>> > > with DEs, although Xfce seems to manage without them and has unmount as
>> > > an only option.
>> 
>> Just got a chance to look at it, has points in common with my problem.
>> It, and related bugs, will be worth a detailed read.
>
> You have *never* explained what *your* problem is. Whatever *you* read
> will not make it any clearer to us what the issue is. It is what *we*
> read which determines what we have to respond to. Could you not be more
> helpful and forthcoming?
>
>> I'm suspecting that there were explicit choices made that I wouldn't.
>
> You can suspect what you like. We would like to know exactly what it
> is that is exercising you.
>
>> Or, to paraphrase a truism, "You can satisfy some of the people all of the
>> time, and all of the people some of the time, but you can not satisfy all of
>> the people all of the time."
>
> Gosh, I wish I had said that!
>

You just broke my ironometer. Thanks a bunch.

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

#195327

FromHenrique de Moraes Holschuh <hmh@debian.org>
Date2018-05-06 13:30 +0200
Message-ID<vMq1z-2Kq-7@gated-at.bofh.it>
In reply to#195299
On Sat, 05 May 2018, Richard Owlett wrote:
> What are the distinguishing features of unmount, Safely Remove Drive, and
> Eject?

Usually it goes like this:

unmount: exactly what it says.  Likely operates only on a single
filesystem (device may have many, if it is partitioned, etc).  Will
flush caches related to that filesystem, and will issue device cache
flushes or write barriers as required, but only related to that
filesystem.

safely remove: unmount all partitions/filesystems; quiesce the device
(flush all caches, plug all read/write queues); issue device quiesce
commands (spin down HDDs, prepare-for-power-off notification for SSDs,
etc); delete it from the kernel (so that it can be physically
hot-removed by the operator, etc).

eject: unmount all partitions/filesystems, issue "media eject" IOCTL
command to device (some card readers, cdrom/cdrw/dvdrom/dvdrw and other
media-tray based devices, etc).  Might or not end up doing nearly the
same as "safely remove", depending on just what the kernel decides to do
when it gets that ioctl (or if some lower level userspace is intelligent
enough to map it to "safely remove", etc).  Does *not* delete the device
from the kernel.

> The question is prompted by observing that for partitions on USB flash
> drives which have been auto-mounted, one or both of the last two are listed
> when clicking on the icon associated with a partition. For a hard disk
> partition, only the first is given.

Next time, give us the name of the DE and application in question.

Anyway, it looks like it is giving you "unmount" when it thinks it is an
unremovable device, and the two others when it thinks either the device
or the media might be removable.

-- 
  Henrique Holschuh

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

#195330

FromRichard Owlett <rowlett@cloud85.net>
Date2018-05-06 14:30 +0200
Message-ID<vMqXD-3kI-1@gated-at.bofh.it>
In reply to#195327
On 05/06/2018 06:23 AM, Henrique de Moraes Holschuh wrote:
> On Sat, 05 May 2018, Richard Owlett wrote:
>> What are the distinguishing features of unmount, Safely Remove Drive, and
>> Eject?
> 
> Usually it goes like this:
> 
> unmount: exactly what it says.  Likely operates only on a single
> filesystem (device may have many, if it is partitioned, etc).  Will
> flush caches related to that filesystem, and will issue device cache
> flushes or write barriers as required, but only related to that
> filesystem.
> 
> safely remove: unmount all partitions/filesystems; quiesce the device
> (flush all caches, plug all read/write queues); issue device quiesce
> commands (spin down HDDs, prepare-for-power-off notification for SSDs,
> etc); delete it from the kernel (so that it can be physically
> hot-removed by the operator, etc).
> 
> eject: unmount all partitions/filesystems, issue "media eject" IOCTL
> command to device (some card readers, cdrom/cdrw/dvdrom/dvdrw and other
> media-tray based devices, etc).  Might or not end up doing nearly the
> same as "safely remove", depending on just what the kernel decides to do
> when it gets that ioctl (or if some lower level userspace is intelligent
> enough to map it to "safely remove", etc).  Does *not* delete the device
> from the kernel.
> 
>> The question is prompted by observing that for partitions on USB flash
>> drives which have been auto-mounted, one or both of the last two are listed
>> when clicking on the icon associated with a partition. For a hard disk
>> partition, only the first is given.
> 
> Next time, give us the name of the DE and application in question.
> 
> Anyway, it looks like it is giving you "unmount" when it thinks it is an
> unremovable device, and the two others when it thinks either the device
> or the media might be removable.
> 

I'm running Debian 9 with MATE.
My observed symptoms were initially observed related to what choices 
given when right clicking on the icon associated with a partition.

I suspect the underlying probably is related to how/when something is 
"auto-magically" mounted. YES, a vague statement. This afternoon I plan 
to run some tests.

Thanks all for feed back received.

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

#195365

FromHenrique de Moraes Holschuh <hmh@debian.org>
Date2018-05-06 23:00 +0200
Message-ID<vMyVh-8mN-31@gated-at.bofh.it>
In reply to#195330
On Sun, 06 May 2018, Richard Owlett wrote:
> On 05/06/2018 06:23 AM, Henrique de Moraes Holschuh wrote:
> > Anyway, it looks like it is giving you "unmount" when it thinks it is an
> > unremovable device, and the two others when it thinks either the device
> > or the media might be removable.
> 
> I'm running Debian 9 with MATE.
> My observed symptoms were initially observed related to what choices given
> when right clicking on the icon associated with a partition.

Ok, so it is the "device/partition is registered as removable" thing, as
hinted by the kernel plus whatever overrides udev/udisks2/MATE has for a
particular device / device type.

> I suspect the underlying probably is related to how/when something is
> "auto-magically" mounted. YES, a vague statement. This afternoon I plan to
> run some tests.

Indeed.  Anyway, FWIW, there are ways (through udev or equivalent) to
change the system's notion of whether a device is removable or not.
Unfortunately, it has been half a decade I needed to mess with this, so
I don't recall the incantations.

As for removable *media* (cdroms, etc), the kernel will return an error
when the eject IOCTL is issued and the operation cannot be performed for
any reason (e.g., you tried it on a SSD/HDD, or the optical drive tray
was locked, or the media is mounted and in use).  I *assume* that
userspace (MATE, udisks, whatever) _might_ decide to (in some
situations), attempt to "safely remove" when the eject IOCTL fails with
an "ioctl innapropriate for this device" error.

-- 
  Henrique Holschuh

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

#195507

FromBrian <ad44@cityscape.co.uk>
Date2018-05-08 21:10 +0200
Message-ID<vNg9P-2pn-7@gated-at.bofh.it>
In reply to#195330
On Sun 06 May 2018 at 07:27:17 -0500, Richard Owlett wrote:

> I'm running Debian 9 with MATE.
> My observed symptoms were initially observed related to what choices given
> when right clicking on the icon associated with a partition.

Are you at liberty to talk about and describe the symptoms in public?

-- 
Brian.

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

#195536

FromRichard Owlett <rowlett@cloud85.net>
Date2018-05-09 20:10 +0200
Message-ID<vNBHk-6SL-11@gated-at.bofh.it>
In reply to#195507
On 05/08/2018 02:09 PM, Brian wrote:
> On Sun 06 May 2018 at 07:27:17 -0500, Richard Owlett wrote:
> 
>> I'm running Debian 9 with MATE.
>> My observed symptoms were initially observed related to what choices given
>> when right clicking on the icon associated with a partition.
> 
> Are you at liberty to talk about and describe the symptoms in public?
> 

After a  brief read of https://bugzilla.gnome.org/show_bug.cgi?id=598690 
I suspect that what's bothering me was done by design. I've got some 
reading ahead.

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

#195538

FromBrian <ad44@cityscape.co.uk>
Date2018-05-09 20:40 +0200
Message-ID<vNCaq-735-7@gated-at.bofh.it>
In reply to#195536
On Wed 09 May 2018 at 13:01:09 -0500, Richard Owlett wrote:

> On 05/08/2018 02:09 PM, Brian wrote:
> > On Sun 06 May 2018 at 07:27:17 -0500, Richard Owlett wrote:
> > 
> > > I'm running Debian 9 with MATE.
> > > My observed symptoms were initially observed related to what choices given
> > > when right clicking on the icon associated with a partition.
> > 
> > Are you at liberty to talk about and describe the symptoms in public?
> > 
> 
> After a  brief read of https://bugzilla.gnome.org/show_bug.cgi?id=598690 I
> suspect that what's bothering me was done by design. I've got some reading
> ahead.

Deconstruction: That's the way it works. (But I would like it to work my
way. Strangely enough - it doesn't work like that).

-- 
Brian.

[toc] | [prev] | [standalone]

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

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

csiph-web