Void Linux discussion
 help / color / mirror / Atom feed
From: JD Robinson <jdrobi...@gmail.com>
To: voidlinux <void...@googlegroups.com>
Subject: (how to) automount USB ports
Date: Fri, 31 Jul 2015 21:54:38 -0700 (PDT)	[thread overview]
Message-ID: <dda816c8-4e16-41f5-a7bf-9f733f8dd997@googlegroups.com> (raw)
In-Reply-To: <d3822a5b-25fc-4bb8-98b7-a5b93b09b578@googlegroups.com>

[-- Attachment #1: Type: text/plain, Size: 2535 bytes --]

There's really no easy solution if say, your lables are changing and so too are the ports your plugging things into.

I'm sadly reminded of why windows uses such things as autorun.inf and am comforted in knowing that Linux DEs can recognize hard drives by UUID and thus mount them automatically. This is usually done via the respective settings because the DE is aware of hot plugging and can restore the state of a session if need be.

That being said. Mounting by UUID is most likely the culprit for remembering hdd USB devices and built ins, however I, myself, have noticed that flash drives are identified by lables and what not.

If you're going to use something like automount you could simply create a folder with whatever name you like and set the appropriate mounting point to the folder. This would be one way to alias a UUID to a folder name without changing any drive parameters and thus be easy to recognize.

As for void, I haven't bothered trying this, even with identical drives and different data on each it becomes a matter of manual intervention since the uuids are all different it makes things easier.

So getting back to autorun.inf, lol, this is an innocuous file that could be used to do things in Linux if you had something you wanted to trigger on automounting.

Autofs and automount or similar daemons should have various ways of identifying drives storage volumes similar to logical volume management, it would just be a matter of setting up your own triggers for where you want things mounted or directed based on what the daemons can see.

I wouldn't rely on devices attached to the USB bus as static or as static as as actual data plugs. These don't change unless you move a plug, but don't quote me on that, this is why things are givemna UUID.

( for void, sv )

Flash drives, thumb drives and phones, etc. aren't as easy to pin down unless you've got sv set up to run a shell scripts as a daemon that looks for dbus events and activities that indicate that your phone or a special device has been plugged in and then what to do with it after that. This wouldn't solve the problem of identical models with different contents, which is why I mention autorun.inf...

Instead I would probably create a file with a file name that's a UUID or an sha1 sum of something random. Place it in the base directory and then have my monitoring daemon mount it according to this.

( I'm going to reread your post since I got a little windy and clarify if need be since I can't reread it while posting from my phone ) 

  reply	other threads:[~2015-08-01  4:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-31 15:19 Userx Xbw
2015-08-01  4:54 ` JD Robinson [this message]
2015-08-01  5:18 ` JD Robinson
2015-08-01 12:47 ` Userx Xbw

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dda816c8-4e16-41f5-a7bf-9f733f8dd997@googlegroups.com \
    --to="jdrobi..."@gmail.com \
    --cc="void..."@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).