Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Patch to usbmount to allow for mountpoint specification #52

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Patch to usbmount to allow for mountpoint specification #52

wants to merge 1 commit into from

Conversation

toys4me
Copy link
Contributor

@toys4me toys4me commented Mar 6, 2013

Mount by UUID or LABEL is currently not implemented in usbmount.
And both methods are often difficult for novice users to use.

This patch adds the idea of a ".mountpoint" file.
If file exists on removable media being mounted, and file contains name/label.
The media will be mounted in /media with the name in the file label.

For example if a hard drive is plugged in and is currently mounted as /media/usb0.
And if user wants to have drive always mount as /media/MyFiles, they can execute:
echo MyFiles > /media/usb0/.mountpoint
Then reboot and from then on the drive will mount as /media/MyFiles

Mount by UUID or LABEL is currently not implemented in usbmount.
And both methods are often difficult for novice users to use.

This patch adds the idea of a ".mountpoint" file.
If file exists on removable media being mounted, and file contains name/label.
The media will be mounted in /media with the name in the file label.

For example if a hard drive is plugged in and is currently mounted as /media/usb0.
And if user wants to have drive always mount as /media/MyFiles, they can execute:
echo MyFiles > /media/usb0/.mountpoint
Then reboot and from then on the drive will moount as /media/MyFiles
@aasoror
Copy link

aasoror commented Mar 6, 2013

cool trick, but if we are over-riding default mount locations why not just use LABEL (or UUID if LABEL is empty), it would achieve the task (fix mount location) and require no intervention from end users.

@davilla
Copy link
Contributor

davilla commented Mar 6, 2013

I've prefer by mount by LABEL be default, that's what users seem to want in the 1st place.

@toys4me
Copy link
Contributor Author

toys4me commented Mar 6, 2013

Guess it would come down to ease of use. At first glance label's would seem to be the easiest solution. But label's can be problematic as there is no consistant way to set the label across file systems types. So method to set a label (ext3,ntfs,xfs) are all different. Duplicate label's are also an issue as all my seagate external usb 2tb drives come from the factory with the same label name. That will be a common issue as using more than one usb storage device is really the only time you really need to start setting a designated mount point.

I was looking for a method to mount drives that would not depend on user knowing details about their drive, its format, and avoid having to have different tutorials for each file system format. The goal was to come up with a method that I could write a two to three line tutorial that would work accross different drives and file systems. No real user knowledge required. So if the user went into usb0 and always wanted that drive to mount as MyDrive they could just:
echo MyDrive > /media/usb0/.mountpoint
No need to know if its exFat, NTFS, ext3, etc. No need to figure out that /dev/sda3 is actually /media/usb0 so you actually have to run the set label command on /dev/sda3.

Fairly quickly I rulled out the possibility of using using UUID. It didn't seem that practical in a novice user environment. UUID's are hard to remember. Looking at two UUID's in the /media directory, an average user isn't going to be able to remember which drive was which and the UUID's are just too long to type if your copying data to them via scp. The whole point of trying to do something like this is to try to make it easier for the user to find where their data is and to make sure it stays there across boots. In my mine UUID's would not be very user friendly at all.

@davilla
Copy link
Contributor

davilla commented Mar 6, 2013

My concern is most users have no clue how to 'echo MyDrive > /media/usb0/.mountpoint' and those that might attempt it will mess it up. Not saying anything bad about users, it's just most have never been exposed to these things. Sort of like, could my mom do this... Unfortunately, the answer would be no.

@aasoror
Copy link

aasoror commented Mar 6, 2013

  • You can have the same duplication issues if someone uses the same "name" inside ".mountpoint".
  • The thing behind LABEL is every OS will have a user friendly way to modify it without you trying to explain to them things like "it must be mountpoint not MOUNTPOINT because linux is case sensitive"
  • From what I have seen, your average user doesn't really care what the labels are, wont bother if you are using LABEL or UUID (except that UUIDs are not visually appealing), if he is using a specific USB storage he probably remembers the contents without the need to memorize its labels, what your average joe user is really concerned about is why does the library he just built no longer works because the mount locations has changed for some reason.

@toys4me
Copy link
Contributor Author

toys4me commented Mar 6, 2013

You think its going to be easier trying to explain how to change disk labels on two hard drives that they just bought at the blue box store, that have the same labels?
They would have to plug drives in a PC or Mac, and have different instructions for each OS.

@davilla
Copy link
Contributor

davilla commented Mar 6, 2013

Not really, I would expect the script to handle duplicate labels in a sensible manner. Normally having mount points move around is not a problem. It's only with xbmc and userdata/libraries which causes this issue.

@toys4me
Copy link
Contributor Author

toys4me commented Mar 6, 2013

@aasoror
Yes they would have the same duplicate problem, if someone put the same name in .mountpoint. But that would be a user generated problem that I believe would be a more rare occurance vs the fairly common occurance of user buying two of same drive and immediately having a label conflict.

Handling a labeling conflict efficiently ends up getting much more complex and is just hard to do when using udev as you end up having the same mount order issue all over again. Which ever one pop's first gets LABEL while which ever drive pop's next will get mounted as ?LABEL?. Which I have to admit is no better or worse off than the situation now with no labels and drives bouncing back and forth. But programatically its a very difficult issue to solve for the user. I spent about a half hour trying to workflow it, and it gets really messy real fast as when first drive mounts you have no idea if there will be a second one, or if the one you have should be the first one or not.

With the simplicity of the .mountpoint method could even build just a very simple python script called "lockmounts" that just enumerates the mounted file systems and generated the required files to lock the current configuration in place. And in theory could run it from xbmc.

Anyway the only reason I came up with this methodolgy as the other posted mount by label methods didn't work well in my environment. As just when I thought I had things configured, would plug in a new drive and boot and things would go sideways again because I forgot to change label on the new drive. With this methodology the first drive stays in place, and all other drives I plug in won't change its mount location unless I accidently create a duplicate name in a .mountpoint file.

Ultimately you are the ones that will end up supporting whatever you put out. So if you can come up with a mount by label method that you can live with and want to support it doesn't really effect me one way or another. As this was a solution I built to solve my problem and that of a friend. Just trying to share what I have come up with as would rather see this kind of stuff integrated into official builds instead of accidently becoming a competing distribution.

@theuni
Copy link
Contributor

theuni commented Mar 6, 2013

Please no. This has been solved over and over again, there's no need for us to solve it too. As I see it, it should go like this:

Udev maps uuid to mount-point. Device is mounted as /media/{uuid}. When XBMC shows a mounted device, it shows label rather than UUID.

@toys4me in general, if you propose changes that require the end-user to take some action (shell access, disk mounting, ssh login, etc), it's probably not going to be something we pull in here. of course there are exceptions to that, but we aim to provide a functional OS out of the box for an end-user.

That said, it's certainly a reasonable idea to add some developer features in optional developer builds.

@toys4me
Copy link
Contributor Author

toys4me commented Mar 6, 2013

I guess my view of this change was a little different that how you all saw it, as i never saw it as requiring the average user to do anything. For the user with one drive, it would always mount as usb0, etc and everything would be great as I wasn't changing the current behaviour of usbmount. For 99% of the users nothing would change from the established behaviour But for the power user with more than one drive, or multiple drives it just gave them the flexibility to easily remap their mount points with a few simple commands and not have to depend on remembering long UUID when they want to copy content to the drive via scp over the network.

If you go the UUID route, you might want to go with the truncated the UUID mountpoint name method that most of the full linux distro's go with. As most users who have USB drives with content, will want to copy content to those drives over the network. Since scp is really the only supported option at this point, typing in full UUID's vs something like usb0, is not going to be very user friendly.

@theuni
Copy link
Contributor

theuni commented Mar 6, 2013

Again, you're thinking like someone who is going to scp. And sure, this would not affect most users, but every extra patch against upstream is an added burden for us now and for the future, so you can't assume these things have no cost.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants