Hi guys,
I was wondering if it's possible to create /media/sdleft and /media/sdright paths that are perminantly linked to the left and right SD card slots? (Regardless of if there's a card in or not)
I find it quite quite confusing when I've been ejecting cards, when they start swapping round, or getting /media/mmcblk2p1 when I've left a terminal open in the path of an SD card I ejected.
Cheers, Marq
On 2012.02.10 12:20, Mark Watkin wrote:
Hi guys,
I was wondering if it's possible to create /media/sdleft and /media/sdright paths that are perminantly linked to the left and right SD card slots? (Regardless of if there's a card in or not)
I find it quite quite confusing when I've been ejecting cards, when they start swapping round, or getting /media/mmcblk2p1 when I've left a terminal open in the path of an SD card I ejected.
you should not eject card without first unmounting it. And you cannot unmount it if terminal's path is in card. So by doing everything right you should not have such problem.
In my opinion idea of sdright/sdleft would be great, but it should appear only if card is inserted (like regular mount folder). Also multi-partition cards should be taken into account if this idea will be implemented
I am resending my response, because I managed to send reply from a non-member account :)
On 2012.02.10 12:20, Mark Watkin wrote:
Hi guys,
I was wondering if it's possible to create /media/sdleft and /media/sdright paths that are perminantly linked to the left and right SD card slots? (Regardless of if there's a card in or not)
I find it quite quite confusing when I've been ejecting cards, when they start swapping round, or getting /media/mmcblk2p1 when I've left a terminal open in the path of an SD card I ejected.
you should not eject card without first unmounting it. And you cannot unmount it if terminal's path is in card. So by doing everything right you should not have such problem.
In my opinion idea of sdright/sdleft would be great, but it should appear only if card is inserted (like regular mount folder). Also multi-partition cards should be taken into account if this idea will be implemented
2012/2/10 Henrik lists@kirneh.eu:
I am resending my response, because I managed to send reply from a non-member account :)
On 2012.02.10 12:20, Mark Watkin wrote:
Hi guys,
I was wondering if it's possible to create /media/sdleft and /media/sdright paths that are perminantly linked to the left and right SD card slots? (Regardless of if there's a card in or not)
I find it quite quite confusing when I've been ejecting cards, when they start swapping round, or getting /media/mmcblk2p1 when I've left a terminal open in the path of an SD card I ejected.
you should not eject card without first unmounting it. And you cannot unmount it if terminal's path is in card. So by doing everything right you should not have such problem.
In my opinion idea of sdright/sdleft would be great, but it should appear only if card is inserted (like regular mount folder). Also multi-partition cards should be taken into account if this idea will be implemented
Firmware-dev mailing list Firmware-dev@openpandora.org http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
If pandora uses udev then doing this would be quite trivial. (Sorry, send duplicate to Henrik. I really should get proper mail client..)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 10.02.2012 11:50, schrieb Jari Vetoniemi:
2012/2/10 Henrik lists@kirneh.eu:
I am resending my response, because I managed to send reply from a non-member account :)
On 2012.02.10 12:20, Mark Watkin wrote:
Hi guys,
I was wondering if it's possible to create /media/sdleft and /media/sdright paths that are perminantly linked to the left and right SD card slots? (Regardless of if there's a card in or not)
I find it quite quite confusing when I've been ejecting cards, when they start swapping round, or getting /media/mmcblk2p1 when I've left a terminal open in the path of an SD card I ejected.
you should not eject card without first unmounting it. And you cannot unmount it if terminal's path is in card. So by doing everything right you should not have such problem.
In my opinion idea of sdright/sdleft would be great, but it should appear only if card is inserted (like regular mount folder). Also multi-partition cards should be taken into account if this idea will be implemented
If pandora uses udev then doing this would be quite trivial. (Sorry, send duplicate to Henrik. I really should get proper mail client..)
Sadly this is not a non trivial task. The problem is that whichever sd card is inserted first gets the "mmcblk1*" identifier and the other one gets the other ID. Yes, there is no explicit differentiation between "slot1" and "slot2".
This is why the setting with "if the sd card is 'named' the name will be used as mountpoint" paradigm is used these days.
Cheers, Nils Kneuper aka Ivanovic
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 10.02.2012 12:29, schrieb Nils Kneuper:
Sadly this is not a non trivial task.
Okay, I have not finished my morning tea... Remove the "non" and make the sentence:
"Sadly this is not a trivial task."
Sorry for anyone I confused... Nils Kneuper aka Ivanovic
There must be some physical characteristic to identify them, like a bus number, otherwise your data reads/writes won't know where to go, though I appreciate it's not trivial, I'm wondering if modding drivers/mmc/card/block.c, on line 475 "devidx = find_first_zero_bit(dev_use, MMC_NUM_MINORS);"
this is what gives it a 0/1/2/etc. If we could pull a bus number, and at least force these to be static per physical device, then could always create a synonym/alias for sdleft and sdright based on that.
The mmc_card structure gives is a host, device and other possibly useful information.
Am I barking up the wrong tree?
Friday, February 10, 2012, 11:29:34 AM, you wrote:
NK> Sadly this is not a non trivial task. The problem is that whichever sd card is NK> inserted first gets the "mmcblk1*" identifier and the other one gets the other NK> ID. Yes, there is no explicit differentiation between "slot1" and "slot2".
NK> This is why the setting with "if the sd card is 'named' the name will be used NK> as mountpoint" paradigm is used these days.
On Fri, Feb 10, 2012 at 12:02:24PM +0000, Mark Watkin wrote:
There must be some physical characteristic to identify them, like a bus number, otherwise your data reads/writes won't know where to go, though I appreciate it's not trivial, I'm wondering if modding drivers/mmc/card/block.c, on line 475 "devidx = find_first_zero_bit(dev_use, MMC_NUM_MINORS);"
this is what gives it a 0/1/2/etc. If we could pull a bus number, and at least force these to be static per physical device, then could always create a synonym/alias for sdleft and sdright based on that.
The mmc_card structure gives is a host, device and other possibly useful information.
Am I barking up the wrong tree?
Please bottom post.
I guess pandora's SD slots work different than your regular SD card reader then. Modding the device drives would be straightest way to go with this. Though, I would like to know how is the current mounting handled, as going far as modifying drivers might be bit overkill.
Hello Jari,
Friday, February 10, 2012, 12:06:31 PM, you wrote:
JV> On Fri, Feb 10, 2012 at 12:02:24PM +0000, Mark Watkin wrote:
There must be some physical characteristic to identify them, like a bus number, otherwise your data reads/writes won't know where to go, though I appreciate it's not trivial, I'm wondering if modding drivers/mmc/card/block.c, on line 475 "devidx = find_first_zero_bit(dev_use, MMC_NUM_MINORS);"
this is what gives it a 0/1/2/etc. If we could pull a bus number, and at least force these to be static per physical device, then could always create a synonym/alias for sdleft and sdright based on that.
The mmc_card structure gives is a host, device and other possibly useful information.
Am I barking up the wrong tree?
JV> Please bottom post.
JV> I guess pandora's SD slots work different than your regular SD JV> card reader then. Modding the device drives would be straightest JV> way to go with this. Though, I would like to know how is the JV> current mounting handled, as going far as modifying drivers JV> might be bit overkill.
Sorry, just used to replying at the top these days.
Why would the Pandora's SD slots be different from any others? Doesn't matter what type of "computer" you are running, you always have to have some way to identify a device uniquely, as I said, otherwise you couldn't send data to it without possibly sending the same data everywhere to everything.
You're right, a driver modification might be overkill, Linux is still pretty much foreign to me, so I'm looking in areas I (think) I understand.
In Windows you can toggle an SD card slot to be visible with or without card, so I figured, why could you not do it on Linux?
That said, I'm not sure if the /dev/ nodes only get created when a card is present, in which case there might be a different option to make it "always exist".
On Fri, 10 Feb 2012, Mark Watkin wrote:
# That said, I'm not sure if the /dev/ nodes only get # created when a card is present, in which case there might be a # different option to make it "always exist".
But why?
If you take your 'games' card out from the left, and put it into the right, and want to copy a game to it.. why woudl you want to remember which slot its in? why not just copy to the 'games' card?
It seems a big improvement the way it is now ;) (Which is the way windows, mac and linux all do it.)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
Friday, February 10, 2012, 3:28:38 PM, you wrote:
s> On Fri, 10 Feb 2012, Mark Watkin wrote:
s> # That said, I'm not sure if the /dev/ nodes only get s> # created when a card is present, in which case there might be a s> # different option to make it "always exist".
s> But why?
s> If you take your 'games' card out from the left, and put it into s> the right, and want to copy a game to it.. why woudl you want to remember s> which slot its in? why not just copy to the 'games' card?
s> It seems a big improvement the way it is now ;) (Which is the way s> windows, mac and linux all do it.)
A couple of things on your reply:
# MiniMenu does not let you "Eject" the SD card, and something tells me I'm not the only person to pop the card out to copy a new PND to it whilst it's turned on.
# Also, you don't get a "/media/games/" for a particular card, otherwise, this would pretty much sort it
The main reason is configuration. I keep my development folder in the right slot off the root of the SD card. However, if I've popped cards in and out, (or just booted without a card in the left slot, or booting from an OS on the left slot), my path is no longer /media/mmcblk1p1. So if I wanted to set config to start in my development folder path, I can't because I can't tell the system where it is for certain.
Hope that helps explain why I'm interested in fixing mount names
Just give your filesystems a name if they are ext2/3 just use : tune2fs /dev/devicename -L codingcard
Cheers, sebt3 ;) 2012/2/10 Mark Watkin pandora@pmprog.co.uk
Friday, February 10, 2012, 3:28:38 PM, you wrote:
s> On Fri, 10 Feb 2012, Mark Watkin wrote:
s> # That said, I'm not sure if the /dev/ nodes only get s> # created when a card is present, in which case there might be a s> # different option to make it "always exist".
s> But why?
s> If you take your 'games' card out from the left, and put it into s> the right, and want to copy a game to it.. why woudl you want to remember s> which slot its in? why not just copy to the 'games' card?
s> It seems a big improvement the way it is now ;) (Which is the way s> windows, mac and linux all do it.)
A couple of things on your reply:
# MiniMenu does not let you "Eject" the SD card, and something tells me I'm not the only person to pop the card out to copy a new PND to it whilst it's turned on.
# Also, you don't get a "/media/games/" for a particular card, otherwise, this would pretty much sort it
The main reason is configuration. I keep my development folder in the right slot off the root of the SD card. However, if I've popped cards in and out, (or just booted without a card in the left slot, or booting from an OS on the left slot), my path is no longer /media/mmcblk1p1. So if I wanted to set config to start in my development folder path, I can't because I can't tell the system where it is for certain.
Hope that helps explain why I'm interested in fixing mount names
Firmware-dev mailing list Firmware-dev@openpandora.org http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
Am Fri, 10 Feb 2012 15:47:56 +0000 hat Mark Watkin pandora@pmprog.co.uk geschrieben:
Friday, February 10, 2012, 3:28:38 PM, you wrote:
s> On Fri, 10 Feb 2012, Mark Watkin wrote:
s> # That said, I'm not sure if the /dev/ nodes only get s> # created when a card is present, in which case there might be a s> # different option to make it "always exist".
s> But why?
s> If you take your 'games' card out from the left, and put s> it into the right, and want to copy a game to it.. why woudl you s> want to remember which slot its in? why not just copy to the s> 'games' card?
s> It seems a big improvement the way it is now ;) (Which is s> the way windows, mac and linux all do it.)
A couple of things on your reply:
# MiniMenu does not let you "Eject" the SD card, and something tells me I'm not the only person to pop the card out to copy a new PND to it whilst it's turned on.
Yes, that's okay as well, we set it upt that this won't hurt the card (as long as you're not writing to it while removing it).
# Also, you don't get a "/media/games/" for a particular card, otherwise, this would pretty much sort it
This works. It has been implemented in Hotfix 3 or something like that (so it goes a long way).
If your card has a label (e.g. "games"), then it will be mounted as /media/games/
Only if it doesn't have a label it will get the /media/mmcblk0p1-Name :)
The main reason is configuration. I keep my development folder in the right slot off the root of the SD card. However, if I've popped cards in and out, (or just booted without a card in the left slot, or booting from an OS on the left slot), my path is no longer /media/mmcblk1p1. So if I wanted to set config to start in my development folder path, I can't because I can't tell the system where it is for certain.
Give those cards a label and you're set :)
Hope that helps explain why I'm interested in fixing mount names
Firmware-dev mailing list Firmware-dev@openpandora.org http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
MM> Give those cards a label and you're set :)
Urm, okay, I feel a little foolish... Cheers guys, I didn't realise I just needed to label (and that I didn't have one on, I usually do, which is why I didn't look for that)
Although annoyingly, they are showing up in all caps (probably because they're labled in Windows). Any way of forcing lower case?
Thanks
On Fri, 10 Feb 2012, Mark Watkin wrote:
# MM> Give those cards a label and you're set :) # # Urm, okay, I feel a little foolish... Cheers guys, I didn't realise I # just needed to label (and that I didn't have one on, I usually do, # which is why I didn't look for that) # # Although annoyingly, they are showing up in all caps (probably because # they're labled in Windows). Any way of forcing lower case?
Name them lowercase :) Windows should be able to do it .. I formatted all mine Fat32 in Windows back months ago, and goot lowercase. ("Foot" is one of mine.)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
Hello skeezix,
Friday, February 10, 2012, 5:41:46 PM, you wrote:
s> On Fri, 10 Feb 2012, Mark Watkin wrote:
# MM>> Give those cards a label and you're set :) s> # s> # Urm, okay, I feel a little foolish... Cheers guys, I didn't realise I s> # just needed to label (and that I didn't have one on, I usually do, s> # which is why I didn't look for that) s> # s> # Although annoyingly, they are showing up in all caps (probably because s> # they're labled in Windows). Any way of forcing lower case?
s> Name them lowercase :) Windows should be able to do it .. I s> formatted all mine Fat32 in Windows back months ago, and goot lowercase. s> ("Foot" is one of mine.)
Come on, I'm not that bad :) I did name it in lower case, but showed in Linux in caps. I'll try again now I'm on my home PC
SN> I join skeezix' opinion: Usually you want to address specific SN> cards rather than specific slots. SN> This can already be done by giving your SD card (partition) a label! SN> Already works for a long time (HF3), as Skeezix reported. SN> (This is the Unix / Mac user's way for device addressing, much SN> more flexible than Windows' drive letter paradigm (IT stone age in my opinion))
Indeed, and that'll work fine for me, the only reason I was looking at fixing "slots" was because I didn't know about the whole label thing :)
Am Fri, 10 Feb 2012 18:56:58 +0000 hat Mark Watkin pandora@pmprog.co.uk geschrieben:
s> Name them lowercase :) Windows should be able to do it .. s> I formatted all mine Fat32 in Windows back months ago, and goot s> lowercase. ("Foot" is one of mine.) Come on, I'm not that bad :) I did name it in lower case, but showed in Linux in caps. I'll try again now I'm on my home PC
Are those FAT16-cards maybe? FAT16 didn't support lower case :)
Hello Michael,
Sunday, February 12, 2012, 11:25:45 PM, you wrote:
MM> Am Fri, 10 Feb 2012 18:56:58 +0000 hat Mark Watkin MM> pandora@pmprog.co.uk geschrieben:
s> Name them lowercase :) Windows should be able to do it .. s> I formatted all mine Fat32 in Windows back months ago, and goot s> lowercase. ("Foot" is one of mine.) Come on, I'm not that bad :) I did name it in lower case, but showed in Linux in caps. I'll try again now I'm on my home PC
MM> Are those FAT16-cards maybe? MM> FAT16 didn't support lower case :)
No, they're definately FAT32, but what I'm reading says you can't do it on them too - at least from Windows.
I'll find another way of relabelling the cards
Concerning lower/upper case labels on FAT32
According to: http://en.wikipedia.org/wiki/FAT32 The label of a FAT32 volume is set (and also looked up) at 2 possible places: * Partition Volume Label (PVL), allows only upper case! * Directory Volume Label (DVL), allows both upper and lower case!
From these facts and my experience, I thus recommend:
If you want to have "good chances" for a lower case label, technically speaking it is important to use a process which changes both PVL or DVL. In practise, set the label to lower case right at formatting time! Because changing to upper case later through GUI processes (such as the file browser), sometimes does not correctly change records, and the label reading processes fall back to the upper-case PVL.
If you want to have guaranteed trouble-free FAT32 labels, I recommend you to intentionally set them to uppercase, as they then will work reliable in all working environments, even those who only consider the always upper case partition volume label.
Its just a bit annoying, as must other Unix paths are lowercase! But hey devs: maybe the default firmware config could be changed to use case-ignore for auto-completion?
SN> Its just a bit annoying, as must other Unix paths are lowercase! SN> But hey devs: maybe the default firmware config could be changed SN> to use case-ignore for auto-completion?
To be honest, the notion of case-sensitive file system is stupid anyway. Could you ever see a reason to have two files with the same name and one starting with an uppercase letter, and the other not?!
Imagine if search engines were case sensitive...
Anyway, I apologise for that little Linux rant.
Case-insensitive autocomplete sounds a great idea, I like it. Would that mean patching sh, and bash, and all the other terminal shells? or would it be a more generic patch applied somewhere else?
On Mon, 13 Feb 2012, Mark Watkin wrote:
# SN> Its just a bit annoying, as must other Unix paths are lowercase! # SN> But hey devs: maybe the default firmware config could be changed # SN> to use case-ignore for auto-completion? # # To be honest, the notion of case-sensitive file system is stupid # anyway. Could you ever see a reason to have two files with the same # name and one starting with an uppercase letter, and the other not?!
Your one-world-or-none perspective is showing again.
Case sensitive and insensitive are both valid ideas; they're different. And yes, I liek them both. I bet you use uppercase in variables names? ;)
# Imagine if search engines were case sensitive...
You often need them to be; acronyms..
# Anyway, I apologise for that little Linux rant.
You do like to show your bias ;)
# Case-insensitive autocomplete sounds a great idea, I like it. Would # that mean patching sh, and bash, and all the other terminal shells? or # would it be a more generic patch applied somewhere else?
More to point, the mount script coudl force lower too..
.. but the rael issue is, why not use lowercase iny our label? ie: It works fine for me, so do _that_; thsts the fix. A workaround is patching what doesn't need patching and risks cascading the issue.
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
s> Case sensitive and insensitive are both valid ideas; they're s> different. And yes, I liek them both. I bet you use uppercase in variables s> names? ;)
Actually, my day job is all VB.NET, and VB.NET names are case-insensitive. Which means you can write them however you want, but you can't have "object", "Object", and "OBJECT"...
You say "one world or none", I don't think that's strictly true - though I am biased, I won't deny that. However, allowing a programmer to define a variable called "object" of type "Object" does not help other developers read and follow the code.
Can you give me one good example where you would want two file names with the same name, just in different casing? I'm not saying it's "wrong", I'm just saying I can't see any possible reason why you would want it like that...
s> # Imagine if search engines were case sensitive...
s> You often need them to be; acronyms..
True, but that's why the boolean operators were added ("+" to force inclusion, "-" to remove, quotes to implement string searches)
s> More to point, the mount script coudl force lower too..
Yep, that'd work too. What script would I need to look at for patching?
s> .. but the rael issue is, why not use lowercase iny our label? ie: s> It works fine for me, so do _that_; thsts the fix. A workaround is s> patching what doesn't need patching and risks cascading the issue.
For the point of the last mail - Windows will not let me set the label on a FAT32 card to lower case, whether I use Windows explorer, or the label commandline
Regards, Marq
Sounds like a bug in Windows. The spec that Microsoft created allows for mixed case labels, and Linux tools allow this to be done. Changing things here would be working around Microsofts failure to follow their own specification which is probably a step in the wrong direction. Does Angstrom have the mtools package somewhere? That would solve the problem without working around or otherwise breaking things, but I can't see it in the repo.
On Mon, Feb 13, 2012 at 1:27 PM, Mark Watkin pandora@pmprog.co.uk wrote:
s> Case sensitive and insensitive are both valid ideas; they're s> different. And yes, I liek them both. I bet you use uppercase in variables s> names? ;)
Actually, my day job is all VB.NET, and VB.NET names are case-insensitive. Which means you can write them however you want, but you can't have "object", "Object", and "OBJECT"...
You say "one world or none", I don't think that's strictly true - though I am biased, I won't deny that. However, allowing a programmer to define a variable called "object" of type "Object" does not help other developers read and follow the code.
Can you give me one good example where you would want two file names with the same name, just in different casing? I'm not saying it's "wrong", I'm just saying I can't see any possible reason why you would want it like that...
s> # Imagine if search engines were case sensitive...
s> You often need them to be; acronyms..
True, but that's why the boolean operators were added ("+" to force inclusion, "-" to remove, quotes to implement string searches)
s> More to point, the mount script coudl force lower too..
Yep, that'd work too. What script would I need to look at for patching?
s> .. but the rael issue is, why not use lowercase iny our label? ie: s> It works fine for me, so do _that_; thsts the fix. A workaround is s> patching what doesn't need patching and risks cascading the issue.
For the point of the last mail - Windows will not let me set the label on a FAT32 card to lower case, whether I use Windows explorer, or the label commandline
Regards, Marq
Firmware-dev mailing list Firmware-dev@openpandora.org http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
On Mon, 13 Feb 2012, David Goldsmith wrote:
# Sounds like a bug in Windows. The spec that Microsoft created allows # for mixed case labels, and Linux tools allow this to be done. # Changing things here would be working around Microsofts failure to # follow their own specification which is probably a step in the wrong # direction. # Does Angstrom have the mtools package somewhere? That would solve the # problem without working around or otherwise breaking things, but I # can't see it in the repo.
Just checked with Windows 7 and Windows XP.
Works!
So... omfg :)
Win 7 let me do it.
Win XP 1) Format -> CaseCheck -> shows as CASECHECK 2) slow-click (F2) rename to CaseCheck -> shows as CASECHECK 3) eject, re-insert.. shows as CaseCheck.
yay for buggy Windows :)
Win XP, trying again:
1) Format -> StuddlyCaps -> shows STUDDLYCAPS 2) Eject, Insert -> STUDDLYCAPS 3) Right click -> rename -> StuddlyCaps -- still shows STUDDLYCAPS F5 REfresh --> shows StuddlyCaps
OKay, so even WinXP can do it, its just silly.
So .. yeah, you're still off your nut :)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
To clarify, since I'm scatterbrained and all over the place today --
I didn't check these again on a Pandora; it might well be that even thoguh Windows now shows it as StuddlyCaps, maybe it shows up in some Unix/Linux distributions as one or the other .. and I'm curious what OS shows.
Almost need a matrix of OS and version and operations to what actually shows up; Windows showing force to upeprcase, then allowing StuddlyCaps after rename, versus OSX and Linux and FreeBSD, say :)
Again, this is why computers suck, when trivial things can take whole essays :)
Anyway, in summary, disk labeling sucks.
jeff
This is Valentines Eve, .. this means I'm on baby duty the entire night so my wife can sleep. Oh god :)
On Mon, 13 Feb 2012, skeezix wrote:
# On Mon, 13 Feb 2012, David Goldsmith wrote: # # # Sounds like a bug in Windows. The spec that Microsoft created allows # # for mixed case labels, and Linux tools allow this to be done. # # Changing things here would be working around Microsofts failure to # # follow their own specification which is probably a step in the wrong # # direction. # # Does Angstrom have the mtools package somewhere? That would solve the # # problem without working around or otherwise breaking things, but I # # can't see it in the repo. # # Just checked with Windows 7 and Windows XP. # # Works! # # So... omfg :) # # Win 7 let me do it. # # Win XP # 1) Format -> CaseCheck -> shows as CASECHECK # 2) slow-click (F2) rename to CaseCheck -> shows as CASECHECK # 3) eject, re-insert.. shows as CaseCheck. # # yay for buggy Windows :) # # Win XP, trying again: # # 1) Format -> StuddlyCaps -> shows STUDDLYCAPS # 2) Eject, Insert -> STUDDLYCAPS # 3) Right click -> rename -> StuddlyCaps # -- still shows STUDDLYCAPS # F5 REfresh # --> shows StuddlyCaps # # OKay, so even WinXP can do it, its just silly. # # So .. yeah, you're still off your nut :) # # jeff # # -- # If everyone would put barbecue sauce on their food, there would be no war. #
-- If everyone would put barbecue sauce on their food, there would be no war.
On 13.02.2012 at 20:37 skeezix wrote:
Again, this is why computers suck, when trivial things can take whole essays :) Anyway, in summary, disk labeling sucks.
BECAUSE I knew how FAT32 label implementations suck, I gave the trivial recommendation:
Use ALLUPPERCASE FAT32 labels! This reliably worked on all OSes I encountered so far!
( And as a Pandora workaround, please give us users the comfort of case-insensitive auto-completion ;-) )
On Mon, 13 Feb 2012, Stefan Nowak wrote:
# > Again, this is why computers suck, when trivial things can take # > whole essays :) Anyway, in summary, disk labeling sucks. # # BECAUSE I knew how FAT32 label implementations suck, I gave the trivial recommendation: # # Use ALLUPPERCASE FAT32 labels! This reliably worked on all OSes I encountered so far! # # ( And as a Pandora workaround, please give us users the comfort of case-insensitive auto-completion ;-) )
FWIW, I've been using mixed case disk labels for years, never really had a problem; mostly its just annoying to type on Pandora so yeah, a mixed case tab-complete would be fine really.
But I use mixed-case labels in Windows and OSX and Linux and Unix and Atari under Mint no problem for quite some time; a single data point, but still :)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
1) Rejecting idea to enforce lowercase enforced mount points. Some people may rely on the upper/lower-case differentiation. Rather provide a PND app for changing (FAT32) label or a wiki-doc on how to do this with already built-in tools. Possible this one already does the job: http://repo.openpandora.org/?page=detail&app=gparted-gparted
2) Bash has the option "completion-ignore-case". I suggest to deliver the firmware with this option set to "On" as a default to ease auto completion especially on the Pandora, where typing SHIFT and a nearby key is not that easy! See my related, yet unanswered, feature request: Pressing SHIFT + any key in sequence creates the modified symbol or action (optionally) http://bugs.openpandora.org/?do=details&task_id=242
3) Case-sensitive vs insensitive: Speaking as an interaction designer: * Insensitiveness has a far higher usability for normal to intermediate users, as the potential confusion and problems exceed the potential benefits by far! * Sensitiveness is useful mostly for expert users. Skeezix gave some examples. Even then, the examples given are rare use cases! In relation to the related problems, it's really not worth it! Sorry Skeezix, I love you usually ;-) but this your standpoint has the taste of "engineer's ivory tower". --> Filesystems are systems which are used for interchange between and by ALL users, thus for them the LOWEST common denominator should be used: Insensitiveness! This is my recommendation. But as Unix IS an expert's system, its offspring cares some of this mindset still with it.
tl;dr -- I did it in Windows and it works, so.. ... yeah, go do it :)
This is an incoherent email, sorry about that; answering and randomly scrolling up and down and tossinfg some bits in.. screaming teething babies downstairs, working right now .. but hey, its a reply, fair warning :)
On Mon, 13 Feb 2012, Mark Watkin wrote:
# s> Case sensitive and insensitive are both valid ideas; they're # s> different. And yes, I liek them both. I bet you use uppercase in variables # s> names? ;) # # Actually, my day job is all VB.NET, and VB.NET names are # case-insensitive. Which means you can write them however you want, but # you can't have "object", "Object", and "OBJECT"...
C# is case sensitive, fwiw; VB is not, due to its old BASIC roots.
For me its a quesiton of .. I don't go into another country and say their ways are incorrect; they are different, and come from a long line of hisotry that makes sense. So.. its okay. It may not be my way, but thats okay.
But looking at it from a purist perspective and ignoring all history, let us continue.
Consideer..
game_assets GameAssets Game Assetes
People love spaces and case in filenames. Thats display mind, we need to keep separate the display versus the sensitivity.
Some systems block having GameAssets and GAMEASSETS but support both clearly, which is not so bad.. but it gets ugly with ambiguouty in resolution sometimes.
Personally, I think its great to have case sensitive display and storage.
I dunno about you, but sometimes you "aid the AID" (AID being an acronym.) It happens.
Microsoft (your ASP boys there ;) spent 20 yuears suggesting people do this:
Class class
ie: Classes with hump, and instanciations in lowercase; Types uppercased. "Int" versus "int", that sort of shenanigans.
Commonly its..
Type variable MACRO
Programming (like math) is a pretty specific thing; clarity matters.
Should this make sense? APPLE = 5 Apple += 1 if ( aPPle == 10 ) ...
Thats not right for vard, or files; it should be consistent, imho.
At the same time, DNS should be case insensitive; thats what you expect.
So the quesiton is.. by context, what does the user expect?
As always, I side with tools doing what they are told, and letting the users dictate policy :)
That said, a lot of peopel don't like sensitivity anymore for some contexts, and thats okay. Display persistance in filenames -- ABSOLUTELY! -- but insensitivyt for uniqueness.. could be. I can see a case either way just fine.
# You say "one world or none", I don't think that's strictly true - though # I am biased, I won't deny that. However, allowing a programmer to # define a variable called "object" of type "Object" does not help other # developers read and follow the code.
Thats why its up to the developer, and the develoepr can chose his language preference; it is not up to us to rule out something.
Some people like operator overloading, some people do not; but it is not for a language designer to decide really -- to force peopel his way or the highway; a tool builder provides features, and lets his users decide what they like to do.
To me, a variable name case _means_ something; that is my choice :)
Lets not go into passwords; losing case sensitivity therw would be absolutely insane, but I donm't thihk you're suggesting an end to that in generral, just in filenames and such.
But I was just razzing you, since this is the third or fourth time in the last couple weeks we've had a commjnications where you've butted heads with some of the Linux or Unix ways of doing something, versus your preferred Windows method; it is just amusing to see the 'mono culture' clash .. you keep running into somethign and thinking 'its wrong!' instead of 'its different, I shoudl try to suss why ahnd figure out if it sucks or not' :)
# Can you give me one good example where you would want two file names # with the same name, just in different casing? I'm not saying it's # "wrong", I'm just saying I can't see any possible reason why you would # want it like that...
I generally don't like that myself; I like the display to have my option of case, and it needs to be stored; Game sometimes, GAME others, it depends on context, though generally I would not use Game and GAME in the same breath.
Mind you, Windows will do tricks .. say you make direcotry Photos, and then you make Photos.txt, and Windows chops off the extensionl you end up with Photos and Photos .. tada, wonderful :) So everything has flaws..
Course, C Macros come to mind, that do that all the time; no namespacing for most of its life, lead to such things.
How many pieces of C code do..
file = fopen (...) And there you end up with "file" of type "FILE"
Talking filenames .. if you have file "Game" and it matches "game" and "GAME" and "GaMe", then suddenly all your path and filename resolution gets pretty complicated and bound to cause bugs and secuerity exploits; best to represent it as is, and let the _user decide_. By the same token, you solve other problems with filename confusion I suppose.
I mean, I dunno about you, but where I work, they loooove there "Big Giant File.xls" with spaces and all sorts of junk in there.
# s> More to point, the mount script coudl force lower too.. # # Yep, that'd work too. What script would I need to look at for # patching?
I would not want such a thing put upstream, for sure; it would be Wrong for Unix, and wrong philosophy.
I forget the name of the ruddy thing offhand; My babies are teething right now, my memory is not very good :)
.. ED did some checks to that 6mo ago, so I shoudl remember, I just can't; check the git :)
# s> .. but the rael issue is, why not use lowercase iny our label? ie: # s> It works fine for me, so do _that_; thsts the fix. A workaround is # s> patching what doesn't need patching and risks cascading the issue. # # For the point of the last mail - Windows will not let me set the # label on a FAT32 card to lower case, whether I use Windows explorer, # or the label commandline
Your'e going to make me reboot to Windows and check again, arent' you?
FWIW, I used Win7 to format my latest cards and named them "Foot" and "Boot" just fine ;)
Windows is _case preserving_ but not _case sensitive_, so should be fine as long as tyou do it at format time.
...
Yep, checked it, works fine. Formatted my SD back to "Boot" no problem.
So you're off your nut ;)
At any rate, the question of filesystem file convention.. thats a little big for us to want to change; I mean, we got 50 years of history here, and we're not going to change Linux for your SD card issue ;)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
s> For me its a quesiton of .. I don't go into another country and s> say their ways are incorrect; they are different, and come from a long s> line of hisotry that makes sense. So.. its okay. It may not be my way, but s> thats okay.
That's fair enough point to make.
s> Programming (like math) is a pretty specific thing; clarity s> matters.
s> Should this make sense? s> APPLE = 5 s> Apple += 1 s> if ( aPPle == 10 ) ...
s> Thats not right for vard, or files; it should be consistent, imho.
Your right, difficult to read, but yes, you have an Apple that starts at 5, ups to 6 and compared to 10.
That said, I suppose the feature of allowing case sensitive names in variables isn't such an issue, because you'll get compile errors.
Writing config files on the other hand, if you mistype in one area, you may end up with two config files. Yes, there are ways to prevent that (like good coding practices), but it seems to be unnecessary.
s> That said, a lot of peopel don't like sensitivity anymore for some s> contexts, and thats okay. Display persistance in filenames -- ABSOLUTELY! s> -- but insensitivyt for uniqueness.. could be. I can see a case either way s> just fine.
I can see the need/want to case-sensitiveness for display purposes - I can totally get that, I even like that, but for opening the file to read contents of, or writing out to...
s> Lets not go into passwords; losing case sensitivity therw would be s> absolutely insane, but I donm't thihk you're suggesting an end to that in s> generral, just in filenames and such.
No, I'm not saying ditch casing, that would be horrible :) I just think in the case of files, it's unnecessary amiguity. I don't know about you, but have you ever seen some people try typing filenames? Forcing them to get the casing right just OTT IMO :)
s> But I was just razzing you, since this is the third or fourth time s> in the last couple weeks we've had a commjnications where you've butted s> heads with some of the Linux or Unix ways of doing something, versus your s> preferred Windows method; it is just amusing to see the 'mono culture' s> clash .. you keep running into somethign and thinking 'its wrong!' instead s> of 'its different, I shoudl try to suss why ahnd figure out if it sucks or s> not' :)
That's why I asked for an example on why you'd need/want case sensitive filenames. I'm drawing blanks. As you said, DNS isn't for a reason - people have to type email addresses and web sites, and could you imagine with the caps lock key on etc. same with files.
However, I do agree, being able to present in a way of your choosing is a good option.
All though to take quick step back - you mention DNS being case insensitive, don't you then find it ironic that on Linux servers, you can type: http://BOARDS.openpandora.ORG/index.php?/topic/7130-pandora-outdated/page__s...
but not: http://boards.openpandora.org/index.PHP?/topic/7130-pandora-outdated/page__s... (caps in the PHP)
Again, I don't say "it's wrong", and the questions I've asked has never been "How do we fix Linux?", it's more "How can I make Linux more comfortable for me?". Isn't that what you said was the strongest point of Linux, all the millions of subsystems you can link to make the perfect match?
Okay, I'm pulling your leg a bit there, but at the same time half serious.
s> Mind you, Windows will do tricks .. say you make direcotry Photos, s> and then you make Photos.txt, and Windows chops off the extensionl you s> end up with Photos and Photos .. tada, wonderful :) So everything has s> flaws..
Oh yes, I'm not afraid to admit that - I remember using Norton disk editor when Windows 95 first let you use long file names and I saw all the additional directory entries. Couldn't believe my eyes.
s> file = fopen (...) s> And there you end up with "file" of type "FILE"
Ugh, nasty, but you're probably right, I bet. I'd always call it fileHnd or if I'm opening several "configFileHnd" etc.
s> I mean, I dunno about you, but where I work, they loooove there s> "Big Giant File.xls" with spaces and all sorts of junk in there.
Yes, but they know if they type in "big giant file.xls" into the open dialog they'll still get the same file. Okay, less of an issue now with GUI dialogs.
s> I would not want such a thing put upstream, for sure; it would be s> Wrong for Unix, and wrong philosophy.
No, but I would never intend pumping such thing into the stream, I just want to make my life easier :)
s> Your'e going to make me reboot to Windows and check again, arent' s> you?
s> ...
s> Yep, checked it, works fine. Formatted my SD back to "Boot" no s> problem.
s> So you're off your nut ;)
Seriously? How the hell did you do that... Here's a video of me doing it. I think YouTube crippled the res a bit, but you should be able to make it out. http://youtu.be/S3GJ9OuU1Oc
:(
s> At any rate, the question of filesystem file convention.. thats a s> little big for us to want to change; I mean, we got 50 years of history s> here, and we're not going to change Linux for your SD card issue ;)
Just because something has been done for so long, doesn't mean it's right ;)
Apparently OS/2 HPFS and MacOS HFS(+) are case insensitive but have case preservation. I wonder if it would be possible to create a bootable SD card for the Pandora with one of these filesystems...
On Fri, 10 Feb 2012, Mark Watkin wrote:
# # MiniMenu does not let you "Eject" the SD card, and something tells # me I'm not the only person to pop the card out to copy a new PND to it # whilst it's turned on.
If you eject in minimenu, it should rescan the app listing (ie: reduce it), and on insert it shoudl scan again (increase it.) Either way, it should not keep a handle to the card.
If it does .. if you eject your card named Games and put it back in, and the old Games is still mounted and you get CrazyName instead..
.. file it as a bug in the tracker and let me know.
ie: That woudl be a mmenu bug, not something to change operations for :)
# # Also, you don't get a "/media/games/" for a particular card, # otherwise, this would pretty much sort it
If your card is called 'games', you'd get /media/games
# The main reason is configuration. I keep my development folder in the # right slot off the root of the SD card. However, if I've popped cards # in and out, (or just booted without a card in the left slot, or # booting from an OS on the left slot), my path is no longer # /media/mmcblk1p1. So if I wanted to set config to start in my # development folder path, I can't because I can't tell the system where # it is for certain.
Name your cards.
If you do not name them, then they get the relatively unpredictable device name. If you name it 'Dev' you'd get /media/Dev, nomatter which slot its in.
This is a Huge Win :)
# Hope that helps explain why I'm interested in fixing mount names
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
On Fri, 10 Feb 2012, Mark Watkin wrote:
# I was wondering if it's possible to create /media/sdleft and # /media/sdright paths that are perminantly linked to the left and # right SD card slots? (Regardless of if there's a card in or not) # # I find it quite quite confusing when I've been ejecting cards, when # they start swapping round, or getting /media/mmcblk2p1 when I've left # a terminal open in the path of an SD card I ejected.
Now remember I don't get to sleep at night anymore for awhile, but..
.. why would you care which slot a card is in? the more important thing is which card, so you can slot data where you want it, no? I suppose if they're both blank and you want to put stuff on the left one that could be handy.. but why not always refer to card by its real name?
Now, if its getting confused over names, then surely its because you're not unmounting and just ejecting .. which is a Bad Idea (even on Windows, which is more permissive.) I forget oif we have caching on or off .. if caching is off, it can slow things down but is more resilient to just ejecting a card; if caching is on, you Really don't want to just eject them.
Just like you never just turn off a PC anymore .. you gotta shut it down, so it things can spin down nice :)
So, uh, yeah, your problem is probabyl caused by being evil to your SD cards ;)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
Let me clarify.. sorry, this is totally the sleep dep talking --
In Windows you're used to 'safely remove disk' and 'eject' and all that; you can do that here too, but I'm not suggesting that.
When I said 'unmount', I am referring to cleanly ejecting; which coudl just be a 'pop it out' and eject, or a full 'eject' type operation. But if you've got an SD card _open_, you've got a terminal on it, or maybe the default browser tool open on it, some program using it.. then the card cannot be cleanly ejected (same on other OSes.)
So if you open an app and point it at your card 'Fooby', and then yank it out, the app still keeps a handle to it and has cached data it can try to work with, but most likely will get all screwed up. Either way, the OS doesn't just dump the card and crash the app, that'd be ugly. So if you then stick it back in, wlel the /media/name (Fooby) is already used, so you get something else.
So really you just need to be careful and eject or unmount cleanly, whcih in practice is trivial .. make sure you're not using it when you yank it out.
Its same as on your desktop, but you as soon as you go to mobile context your (quite rightly) switch contexts in your brain and treat it differently, but in our case, its not different. On a PSP or whatever you asre free to yank it out willy nilly since the (in that case) card is really not used for anythign except say saves, discretely.
jeff
On Fri, 10 Feb 2012, skeezix wrote:
# On Fri, 10 Feb 2012, Mark Watkin wrote: # # # I was wondering if it's possible to create /media/sdleft and # # /media/sdright paths that are perminantly linked to the left and # # right SD card slots? (Regardless of if there's a card in or not) # # # # I find it quite quite confusing when I've been ejecting cards, when # # they start swapping round, or getting /media/mmcblk2p1 when I've left # # a terminal open in the path of an SD card I ejected. # # Now remember I don't get to sleep at night anymore for awhile, # but.. # # .. why would you care which slot a card is in? the more important # thing is which card, so you can slot data where you want it, no? I suppose # if they're both blank and you want to put stuff on the left one that could # be handy.. but why not always refer to card by its real name? # # Now, if its getting confused over names, then surely its because # you're not unmounting and just ejecting .. which is a Bad Idea (even on # Windows, which is more permissive.) I forget oif we have caching on or # off .. if caching is off, it can slow things down but is more resilient to # just ejecting a card; if caching is on, you Really don't want to just # eject them. # # Just like you never just turn off a PC anymore .. you gotta shut # it down, so it things can spin down nice :) # # So, uh, yeah, your problem is probabyl caused by being evil to # your SD cards ;) # # jeff # # -- # If everyone would put barbecue sauce on their food, there would be no war. #
-- If everyone would put barbecue sauce on their food, there would be no war.
I join skeezix' opinion: Usually you want to address specific cards rather than specific slots. This can already be done by giving your SD card (partition) a label! Already works for a long time (HF3), as Skeezix reported. (This is the Unix / Mac user's way for device addressing, much more flexible than Windows' drive letter paradigm (IT stone age in my opinion))
Nevertheless, there are some use cases where one wants to specifically address certain slots (buses). - Instructions which use filepaths to a certain slot, where the user trusts entirely on slot position. - Batch processes on consecutively inserted/removed SD cards in a certain slot.