Patch to usbmount to allow for mountpoint specification #52
Conversation
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
|
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. |
|
I've prefer by mount by LABEL be default, that's what users seem to want in the 1st place. |
|
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: 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. |
|
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. |
|
|
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? |
|
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. |
|
@aasoror 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. |
|
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. |
|
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. |
|
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. |
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