| 1 |
On Thu, May 3, 2012 at 6:00 PM, walt <w41ter@×××××.com> wrote: |
| 2 |
> On 05/03/2012 02:48 PM, Canek Peláez Valdés wrote: |
| 3 |
>> On Thu, May 3, 2012 at 3:18 PM, walt <w41ter@×××××.com> wrote: |
| 4 |
>>> On 04/13/2012 05:19 PM, walt wrote: |
| 5 |
>>>> |
| 6 |
>>>> A recent update |
| 7 |
>>>> (udev?) on my ~amd64 machines is now mounting removable drives |
| 8 |
>>>> on /run/media instead of /media. |
| 9 |
>>> |
| 10 |
>>> |
| 11 |
>>> Ha! I should have suspected Lennart from the beginning: |
| 12 |
>>> |
| 13 |
>>> http://cgit.freedesktop.org/systemd/systemd/commit/?id=231931ffba1bca9d8759bbd6f797e56f8c6971fa |
| 14 |
>> |
| 15 |
>> The link you posted has nothing to do with this; that's only a |
| 16 |
>> systemd-specific change in response to a change in udisks2. In other |
| 17 |
>> words, Lennart has nothing to do with this change, the responsible is |
| 18 |
>> David Zeuthen, udisks2 maintainer: |
| 19 |
>> |
| 20 |
>> https://plus.google.com/u/0/110773474140772402317/posts/NqPUifsFUYH |
| 21 |
> |
| 22 |
> Thanks for the correction. |
| 23 |
> |
| 24 |
>> And it's actually a pretty reasonable change (IMHO): now in multiseat |
| 25 |
>> configurations each user can plug a USB drive and only him/she will |
| 26 |
>> see it |
| 27 |
> |
| 28 |
> I've thought that for a long time. Mounting my own "personal mount" on |
| 29 |
> a system directory never made any sense to me. However, /run/media is |
| 30 |
> still a system directory, so it still doesn't make any sense to me. |
| 31 |
> |
| 32 |
> I think /home/wa1ter/media is a more logical choice. But I'm not doing |
| 33 |
> the coding in this bazaar ;) |
| 34 |
> |
| 35 |
> The upstream dev(s) seem intent on mounting removable media on a tempfs |
| 36 |
> for some reason. Do you know why? |
| 37 |
|
| 38 |
So the mountpoint can be created on the fly, and so it is also |
| 39 |
volatile. The system could "mkdir /media/<mountpoint>" everytime a USB |
| 40 |
is plugged, and then "rmdir /media/<mountpoint>" when it's unplugged; |
| 41 |
but if something happens (a power failure or something similar), then |
| 42 |
you would need to manually remove the stale dir, or have a process do |
| 43 |
it from time to time. Actually, some years ago it was not rare to have |
| 44 |
such stale directories under /media. |
| 45 |
|
| 46 |
None of this happens with a tmpfs. |
| 47 |
|
| 48 |
> I understand completely the reason for inventing /run and making it a |
| 49 |
> tempfs (I think Lennart *was* involved in that), but why use /run when |
| 50 |
> it's not necessary or (IMHO) logical? |
| 51 |
|
| 52 |
I don't know, really. gvfs (the new virtual filesystem for GNOME) |
| 53 |
mounts the remote shares in $HOME/.gvfs (which is also a tmpfs). I |
| 54 |
suppose a $HOME/.mount could be created. |
| 55 |
|
| 56 |
I personally don't care, but it is certainly not consistent. However, |
| 57 |
I agree with the idea of getting rid of the /media dir, and I have not |
| 58 |
used /mnt in years, so I'm thinking on deleting both so my root dir is |
| 59 |
cleaner. |
| 60 |
|
| 61 |
Regards. |
| 62 |
-- |
| 63 |
Canek Peláez Valdés |
| 64 |
Posgrado en Ciencia e Ingeniería de la Computación |
| 65 |
Universidad Nacional Autónoma de México |
Archives