On Mon, 2007-02-12 at 18:20 -0600, Mike McCarty wrote: > IMO, mounting by "volume name" is a very poor way to do things. Okay, you have some program, let's call it SuperThing. It has a collection of discs because that's how it comes. At some stage it wants its disc one, later on it wants its disc two, and so on. It can ask you to insert disc 1, and mount a disc called SuperThing1, and find it at /media/SuperThing1, and so on for the rest. Conversely, it could not ask you to insert disc 1, and know for certain that it's going to be mounted at /media/cdrom, because different distros and releases have different default mount points (in /media or /mnt, as cdrom, cdwriter, or somethng else, etc.), not to mention personal user configuration preferences for that sort of thing. Also, for it to work out that it's had disc 1 inserted, and not disc 2, it has to check for that. That can also be done by the volume name. Or, has to be done by saving a file onto the disc with a specific file name, and perhaps with specific details in it. Why bother with that *extra* step? For multi-disc sets, and multi-disc-drive systems, you can leave all the discs inserted in anywhere, and the application can find them by name. It can't do that if they have generically vague, and/or varying mount points. I have the same issue with things like USB flash drives. I far rather finding my drive in the tree by name, rather than the stupidly vague /media/usbdisk, which is indistinguishable than the other /media/usbdisk1, /media/usbdisk2, and so on, drives on my system. Even more so when what was disk1 beforehand becomes disk2 later on, and you have to trawl through the files in each of them to find the one you want. > Applications should have configuration files put into standard > locations which tell them where to find their data. This would > be > > $HOME/.my_application/<application specific configuration> That's fine for local data. Not much good for something on a separate removable media (e.g. last weeks back-ups).
