A while back I got help in getting my Palm Pilot to connect to CentOS, and through the advice I got here I was able to successfully back up my files to the computer using the CentOS default Palm utility.
However, I now want to use JPilot to sync and install files. But when I attempt to sync through JPilot, I get the following error: ******************************* Syncing on device /dev/pilot Press the Hotsync button now ******************************* pi_bind Invalid argument Check your serial port and settings Exiting with status SYNC_ERROR_BIND Finished
I searched on the net, and it would seem that this is because of a permissions problem with the /dev/pilot files. The advice I am following is here: http://www.brandonhutchinson.com/Running_JPilot_as_a_non-privileged_user.htm...
On this page the writer says that there are two ways to solve the problem - make the user the owner of the device, or make the device world writable. The author of the page says "making files (especially devices) world-writable should be avoided", but I think I'm not bothered either way.
In any case, when it comes to making the device owned by anyone or world-writable, I'm not sure how to proceed. Retracing some of the steps given tome on this list before, I can see that the relevant device files have the following permissions: [root@localhost dev]# ls -l /dev/ttyUSB* /dev/pilot lrwxrwxrwx 1 root root 7 Sep 3 11:57 /dev/pilot -> ttyUSB1 crw-rw---- 1 root uucp 188, 0 Sep 3 11:57 /dev/ttyUSB0 crw------- 1 dave uucp 188, 1 Sep 3 11:57 /dev/ttyUSB1
So, I either want to give the user "dave" permission to use ttyUSB 1 and 0, or make those files world-writable.
But where I hit a wall is that I can't figure out how to change the permissions on these files because they only appear when I hot sync the palm, a process that only lasts for a few seconds, maybe 15 or 20 at the most, and also tends to get enough attention from the CPU to make it so it's tough to switch to the command line and enter in any commands in time. I tried the following, but the settings don't seem to stick for the next sync operation: [root@localhost dev]# chown dave /dev/ttyUSB0 /dev/ttyUSB1
The advice I got last time on this list did speak about permissions, but unfortunately, I didn't pursue the issue because I thought the issue had been solved when I was able to make the basic connection at all to CentOS.
So my question is, how do I change permission on these temporarily existing device files to that JPilot will not return errors?
Dave
On Sat, 3 Sep 2005, Dave Gutteridge wrote:
A while back I got help in getting my Palm Pilot to connect to CentOS, and through the advice I got here I was able to successfully back up my files to the computer using the CentOS default Palm utility.
http://www.clasohm.com/blog/one-entry?entry_id=12096
Thank you for that link. However, it is full of advice that is hard to follow. Things like "Change /etc/udev/rules.d/10-visor.rules so that udev does not touch the Palm ttyUSB device nodes", which is something I don't know how to do.
Anyway, I did my best to try and follow some of the instructions. It said to press the hotsync button on the palm, and then "cp -a" the files that appear, and then change the permissions on the resulting files. So I tried that and got this result:
[root@localhost dev]# ls -l /dev/ttyUSB* /dev/pilot lrwxrwxrwx 1 root root 7 Sep 3 22:25 /dev/pilot -> ttyUSB1 crw-rw---- 1 root uucp 188, 0 Sep 3 22:25 /dev/ttyUSB0 crw------- 1 dave uucp 188, 1 Sep 3 22:25 /dev/ttyUSB1 [root@localhost dev]# cp -a /dev/pilot pilot
... but wait. If I name the file the same thing, then it says file already exists. If I name it something else, it has nothing to do with the files that Jpilot is looking for.
Can someone break this down into something a little simpler? I'm a newbie here, and the wealth of information on that page isn't exactly designed to be easily accessible.
Dave
On Sat, 2005-09-03 at 22:34 +0900, Dave Gutteridge wrote:
Thank you for that link. However, it is full of advice that is hard to follow. Things like "Change /etc/udev/rules.d/10-visor.rules so that udev does not touch the Palm ttyUSB device nodes", which is something I don't know how to do.
Anyway, I did my best to try and follow some of the instructions. It said to press the hotsync button on the palm, and then "cp -a" the files that appear, and then change the permissions on the resulting files. So I tried that and got this result:
[root@localhost dev]# ls -l /dev/ttyUSB* /dev/pilot lrwxrwxrwx 1 root root 7 Sep 3 22:25 /dev/pilot -> ttyUSB1 crw-rw---- 1 root uucp 188, 0 Sep 3 22:25 /dev/ttyUSB0 crw------- 1 dave uucp 188, 1 Sep 3 22:25 /dev/ttyUSB1 [root@localhost dev]# cp -a /dev/pilot pilot
... but wait. If I name the file the same thing, then it says file already exists. If I name it something else, it has nothing to do with the files that Jpilot is looking for.
Can someone break this down into something a little simpler? I'm a newbie here, and the wealth of information on that page isn't exactly designed to be easily accessible.
Dave
Dave .... did you
create a file named:
/etc/udev/rules.d/10-visor.rules
and put this in it:
BUS="usb", SYSFS{product}="Palm Handheld*", KERNEL="ttyUSB[13579]", SYMLINK="pilot"
create a file named: /etc/udev/rules.d/10-visor.rules and put this in it: BUS="usb", SYSFS{product}="Palm Handheld*", KERNEL="ttyUSB[13579]", SYMLINK="pilot"
Sort of. Based on advice I got earlier, I have a file with the slightly different name "10-visor-rules", and the line inside is a little different too: BUS="usb", SYSFS {product}="Palm Handheld", KERNEL="ttyUSB[13579]", SYMLINK="pilot" ... (there's no asterix after the word "Handheld")
Which should it be, and will this resolve the permissions settings?
Dave
On Sun, 2005-09-04 at 01:21 +0900, Dave Gutteridge wrote:
create a file named: /etc/udev/rules.d/10-visor.rules and put this in it: BUS="usb", SYSFS{product}="Palm Handheld*", KERNEL="ttyUSB[13579]", SYMLINK="pilot"
Sort of. Based on advice I got earlier, I have a file with the slightly different name "10-visor-rules", and the line inside is a little different too: BUS="usb", SYSFS {product}="Palm Handheld", KERNEL="ttyUSB[13579]", SYMLINK="pilot" ... (there's no asterix after the word "Handheld")
Which should it be, and will this resolve the permissions settings?
I am pretty sure it needs to be named .rules in the /etc/udev/rules.d directory.
using the * is also good
I think it should create files with the user as the owner ... which should work for you.
Do another ls -al on those created files after making those adjustments.
Do another ls -al on those created files after making those adjustments.
Thank you for the advice. I've created a 10-visor.rules file with the line as you had it written, and removed the old file just to be sure.
Unfortunately, it looks as though the permission settings are exactly the same as before.
Here it is now: [root@localhost rules.d]# ls -al /dev/ttyUSB* /dev/pilot lrwxrwxrwx 1 root root 7 Sep 4 01:54 /dev/pilot -> ttyUSB1 crw-rw---- 1 root uucp 188, 0 Sep 4 01:54 /dev/ttyUSB0 crw------- 1 dave uucp 188, 1 Sep 4 01:54 /dev/ttyUSB1
Here is what it was: [root@localhost dev]# ls -l /dev/ttyUSB* /dev/pilot lrwxrwxrwx 1 root root 7 Sep 3 11:57 /dev/pilot -> ttyUSB1 crw-rw---- 1 root uucp 188, 0 Sep 3 11:57 /dev/ttyUSB0 crw------- 1 dave uucp 188, 1 Sep 3 11:57 /dev/ttyUSB1
Is there anything I can do in the 10-visor.rules file or elsewhere that will force the tty files to be created with permissions accessible by the user "dave"?
Dave
On Sun, 2005-09-04 at 02:01 +0900, Dave Gutteridge wrote:
Do another ls -al on those created files after making those adjustments.
Thank you for the advice. I've created a 10-visor.rules file with the line as you had it written, and removed the old file just to be sure.
Unfortunately, it looks as though the permission settings are exactly the same as before.
Here it is now: [root@localhost rules.d]# ls -al /dev/ttyUSB* /dev/pilot lrwxrwxrwx 1 root root 7 Sep 4 01:54 /dev/pilot -> ttyUSB1 crw-rw---- 1 root uucp 188, 0 Sep 4 01:54 /dev/ttyUSB0 crw------- 1 dave uucp 188, 1 Sep 4 01:54 /dev/ttyUSB1
Here is what it was: [root@localhost dev]# ls -l /dev/ttyUSB* /dev/pilot lrwxrwxrwx 1 root root 7 Sep 3 11:57 /dev/pilot -> ttyUSB1 crw-rw---- 1 root uucp 188, 0 Sep 3 11:57 /dev/ttyUSB0 crw------- 1 dave uucp 188, 1 Sep 3 11:57 /dev/ttyUSB1
Is there anything I can do in the 10-visor.rules file or elsewhere that will force the tty files to be created with permissions accessible by the user "dave"?
---- If you look at the above - it already is usable (in fact owned) by the user dave.
/dev/pilot is a link which has all permissions - normal for a link since the link doesn't make the call about permissions. It is a link to ttyUSB1 which as you see is a block device owned by dave (and dave has read/write permissions).
make sure that 'jpilot' or any other program that you wish to use to sync your Palm, uses /dev/pilot
Also note - /dev/pilot, /dev/ttyUSB0 and /dev/ttyUSB1 only exist when the sync is chosen on the handheld or the cradle. Once that has completed or given up, an 'ls -l /dev/pilot /dev/ttyUSB*' should/will return nothing
Craig
If you look at the above - it already is usable (in fact owned) by the user dave.
Well, if you say so, I believe you. The reason I think I don't have the correct permissions settings is because on the following web page, it says that the error I get is because the permissions are wrong. If I already have the "correct" permissions settings, and I still get this error, then I'm at a loss to diagnose the problem. http://www.brandonhutchinson.com/Running_JPilot_as_a_non-privileged_user.htm...
make sure that 'jpilot' or any other program that you wish to use to sync your Palm, uses /dev/pilot
In the JPilot preferences page, it has a field for entering in "Serial Port". In that field I have "/dev/pilot". There does not seem to be an option or way to specify whether or not the connection is USB, but I assume if it's going to /dev/pilot then it should be looking in the right place...?
Dave
On Sun, 2005-09-04 at 12:30 +0900, Dave Gutteridge wrote:
If you look at the above - it already is usable (in fact owned) by the user dave.
Well, if you say so, I believe you. The reason I think I don't have the correct permissions settings is because on the following web page, it says that the error I get is because the permissions are wrong. If I already have the "correct" permissions settings, and I still get this error, then I'm at a loss to diagnose the problem. http://www.brandonhutchinson.com/Running_JPilot_as_a_non-privileged_user.htm...
make sure that 'jpilot' or any other program that you wish to use to sync your Palm, uses /dev/pilot
In the JPilot preferences page, it has a field for entering in "Serial Port". In that field I have "/dev/pilot". There does not seem to be an option or way to specify whether or not the connection is USB, but I assume if it's going to /dev/pilot then it should be looking in the right place...?
It looks like /dev/pilot is owned by you, but (iirc) the palms/visors and such use /dev/pilot and one other USB channel to do the sync. Based on your earlier comments, it look like it might require you to also own /dev/ttyUSB0. One thing that you might be able to do is use
/etc/security/console.perms
Add the following entries (below the comments)
# device classes -- these are shell-style globs <pilot> /dev/ttyUSB*
# permission definitions <console> 0660 <pilot> 0660 root.uucp
Then log off and back in. This should set things up so that the person logged in on the machine console (X or virtual console) will own these devices.
On Sat, 2005-09-03 at 20:43 -0700, I wrote:
It looks like /dev/pilot is owned by you, but (iirc) the palms/visors and such use /dev/pilot and one other USB channel to do the sync. Based on your earlier comments, it look like it might require you to also own /dev/ttyUSB0. One thing that you might be able to do is use
/etc/security/console.perms
Add the following entries (below the comments)
# device classes -- these are shell-style globs <pilot> /dev/ttyUSB*
# permission definitions <console> 0660 <pilot> 0660 root.uucp
Then log off and back in. This should set things up so that the person logged in on the machine console (X or virtual console) will own these devices.
Now that I think about it, will the /etc/console.perms stuff work with udev devices?
I don't have a palm, so it's a bit difficult to test. This was based on some work I did for someone under RHL 9. It does look like you might be able to cheese the /etc/udev/permissions.d/50-udev.permissions to set the permissions to something other than:
ttyUSB*:root:uucp:0660
Maybe just make them world writable (fine for single user machines)
ttyUSB*:root:uucp:0666
OR
ttyUSB*:root:pilot:0660
and add yourself to the pilot group. OR, simply add yourself to the uucp group :)
On Sat, 2005-09-03 at 20:43 -0700, Sean O'Connell wrote:
On Sun, 2005-09-04 at 12:30 +0900, Dave Gutteridge wrote:
If you look at the above - it already is usable (in fact owned) by the user dave.
Well, if you say so, I believe you. The reason I think I don't have the correct permissions settings is because on the following web page, it says that the error I get is because the permissions are wrong. If I already have the "correct" permissions settings, and I still get this error, then I'm at a loss to diagnose the problem. http://www.brandonhutchinson.com/Running_JPilot_as_a_non-privileged_user.htm...
make sure that 'jpilot' or any other program that you wish to use to sync your Palm, uses /dev/pilot
In the JPilot preferences page, it has a field for entering in "Serial Port". In that field I have "/dev/pilot". There does not seem to be an option or way to specify whether or not the connection is USB, but I assume if it's going to /dev/pilot then it should be looking in the right place...?
It looks like /dev/pilot is owned by you, but (iirc) the palms/visors and such use /dev/pilot and one other USB channel to do the sync. Based on your earlier comments, it look like it might require you to also own /dev/ttyUSB0. One thing that you might be able to do is use
/etc/security/console.perms
Add the following entries (below the comments)
# device classes -- these are shell-style globs <pilot> /dev/ttyUSB*
# permission definitions <console> 0660 <pilot> 0660 root.uucp
Then log off and back in. This should set things up so that the person logged in on the machine console (X or virtual console) will own these devices.
---- /etc/security/console.perms would clearly be the wrong place to do that
this is udev stuff...
evidently this is in a state of flux but on FC-3 and I would presume CentOS-4 you would want to have an entry... # cat /etc/udev/permissions.d/10-udev.permissions #set Palm Pilot rwx pilot*:root:usb:0666 pilot*:craig:usb:0666
Craig
/etc/security/console.perms would clearly be the wrong place to do that this is udev stuff...
Perhaps you could explain why iyt's the wrong place to do this stuff. I'm a newbie, and it's not clear. Also, I followed that advice, and it seems to have helped. I also did your cat command, and I'm not really sure what it did, but it returned the result you said it would.
if you are syncing, /dev/pilot is a symbolic link to /dev/ttyUSB1 what more do you think that you need?
I don't know what I need, I just know what I'm trying to achieve. In JPilot, I want to be able to sync, and to install .prc files. When I took the error message I got and looked it up on the net, it said it was a permissions problem. So if the permissions for /dev/pilot and/or /dev/ttyUSB1 are, according to you, what they should be, and other web pages say that the permissions are what is stopping it from working, then I have no idea what I need.
In any case, the error situation has changed. Now that I have edited console.perms, when I hit the sync button and add a .prc file to load, it first gives me the same error as before. But if I press the sync again, it says the following: J-Pilot: sync PID = 4920 J-Pilot: press the hotsync button on the cradle or "kill 4920"
However, pressing hotsync produced no results.
So I have clearly not yet solved the problem. But now I don't know if it's a permissions issue or not, because I seem to be getting told here that the permissions are set okay, but the error message is, according to some web sites, a symptom of permission problems.
I'm quite confused. More than when I started.
Dave
On Mon, 2005-09-05 at 01:14 +0900, Dave Gutteridge wrote:
/etc/security/console.perms would clearly be the wrong place to do that this is udev stuff...
Perhaps you could explain why iyt's the wrong place to do this stuff. I'm a newbie, and it's not clear. Also, I followed that advice, and it seems to have helped. I also did your cat command, and I'm not really sure what it did, but it returned the result you said it would.
if you are syncing, /dev/pilot is a symbolic link to /dev/ttyUSB1 what more do you think that you need?
I don't know what I need, I just know what I'm trying to achieve. In JPilot, I want to be able to sync, and to install .prc files. When I took the error message I got and looked it up on the net, it said it was a permissions problem. So if the permissions for /dev/pilot and/or /dev/ttyUSB1 are, according to you, what they should be, and other web pages say that the permissions are what is stopping it from working, then I have no idea what I need.
In any case, the error situation has changed. Now that I have edited console.perms, when I hit the sync button and add a .prc file to load, it first gives me the same error as before. But if I press the sync again, it says the following: J-Pilot: sync PID = 4920 J-Pilot: press the hotsync button on the cradle or "kill 4920"
However, pressing hotsync produced no results.
So I have clearly not yet solved the problem. But now I don't know if it's a permissions issue or not, because I seem to be getting told here that the permissions are set okay, but the error message is, according to some web sites, a symptom of permission problems.
I'm quite confused. More than when I started.
---- well before you can load a program (prc), you have to be able to sync.
jpilot - I thought was one of the easiest of all to make work - it really didn't seem to require much - unlike some issues that I had with gpilot (gnome/evolution).
First off...
without sync'ing anything
ls -l /dev/pilot /dev/ttyUSB*
should come up empty...please confirm
then press the sync button on the cradle or 'Hotsync' on your palm and tell it to connect (I presume that you are using pretty normal settings...USB - 576000 - flow control automatic
then again... ls -l /dev/pilot /dev/ttyUSB*
you should see 3 things happening...
# ls -l /dev/pilot /dev/ttyUSB* lrwxrwxrwx 1 root root 7 Sep 4 20:07 /dev/pilot -> ttyUSB1 crw-rw---- 1 root uucp 188, 0 Sep 4 20:07 /dev/ttyUSB0 crw------- 1 craig uucp 188, 1 Sep 4 20:07 /dev/ttyUSB1
look familiar? I just checked it - sync'd with gpilot (gnome- pilotd/evolution) and jpilot (for s&g's)
granted this is FC-3 and not CentOS 4 because I use Fedora for my desktop but they should be nearly identical for this purpose.
so I would say that if you don't have those devices when you aren't syncing and you do have those devices when you push the sync button on the cradle or on the palm - if jpilot is set to use /dev/pilot then the only issue I can see is the settings... 57600 & auto flow control works for me.
Perhaps you should make sure that you don't have some old processes hanging and reboot first.
I think your permissions thing is just a red herring - or in the thread beginning - advice from RedHat 8 which simply doesn't apply.
Craig
ls -l /dev/pilot /dev/ttyUSB* should come up empty...please confirm
Confirmed: [dave@localhost ~]$ ls -l /dev/pilot /dev/ttyUSB* ls: /dev/pilot: No such file or directory ls: /dev/ttyUSB*: No such file or directory
then again... ls -l /dev/pilot /dev/ttyUSB* you should see 3 things happening...
And I do: [dave@localhost ~]$ ls -l /dev/pilot /dev/ttyUSB* lrwxrwxrwx 1 root root 7 Sep 5 20:38 /dev/pilot -> ttyUSB1 crw-rw---- 1 dave uucp 188, 0 Sep 5 20:38 /dev/ttyUSB0 crw-rw---- 1 dave uucp 188, 1 Sep 5 20:38 /dev/ttyUSB1
so I would say that if you don't have those devices when you aren't syncing and you do have those devices when you push the sync button on the cradle or on the palm - if jpilot is set to use /dev/pilot then the only issue I can see is the settings... 57600 & auto flow control works for me.
I don't see a setting for "auto flow control" in Jpilot. But I do have it set to 57600.
Perhaps you should make sure that you don't have some old processes hanging and reboot first.
Sorry, I'm not sure what you mean by this. Processes related to the palm pilot?
Dave
On Mon, 2005-09-05 at 20:54 +0900, Dave Gutteridge wrote:
ls -l /dev/pilot /dev/ttyUSB* should come up empty...please confirm
Confirmed: [dave@localhost ~]$ ls -l /dev/pilot /dev/ttyUSB* ls: /dev/pilot: No such file or directory ls: /dev/ttyUSB*: No such file or directory
then again... ls -l /dev/pilot /dev/ttyUSB* you should see 3 things happening...
And I do: [dave@localhost ~]$ ls -l /dev/pilot /dev/ttyUSB* lrwxrwxrwx 1 root root 7 Sep 5 20:38 /dev/pilot -> ttyUSB1 crw-rw---- 1 dave uucp 188, 0 Sep 5 20:38 /dev/ttyUSB0 crw-rw---- 1 dave uucp 188, 1 Sep 5 20:38 /dev/ttyUSB1
---- so far pretty good - though /dev/ttyUSB0 is owned by dave which means that you succeeded in mucking the permissions which obviously wasn't the problem as that should have been owned by root. ----
so I would say that if you don't have those devices when you aren't syncing and you do have those devices when you push the sync button on the cradle or on the palm - if jpilot is set to use /dev/pilot then the only issue I can see is the settings... 57600 & auto flow control works for me.
I don't see a setting for "auto flow control" in Jpilot. But I do have it set to 57600.
---- I meant the palm pilot - making sure it is set to 57600 and auto-flow ----
Perhaps you should make sure that you don't have some old processes hanging and reboot first.
Sorry, I'm not sure what you mean by this. Processes related to the palm pilot?
---- yes - and the usb drivers - try the windows fix - reboot the system.
Craig
I meant the palm pilot - making sure it is set to 57600 and auto-flow
Oh, I see. Yes, the Palm Pilot is set to 57600 and automatic flow.
yes - and the usb drivers - try the windows fix - reboot the system.
System rebooted, and yet still it's coming up with the same error. However, now that you've convinced me that it's probably not a permissions issue, I've been wondering if maybe I'm just not understanding the set up. For example, I thought gpilot was necessary in order to have connection to the Palm Pilot. But should I be running either Jpilot or Gpilot, or both? Also, what I've determined about Jpilot is that the error comes up before I hit the sync button on the Pilot. But then when I hit the sync pilot on the Pilot, and return to JPilot, it can't find the Pilot. I've tried finding clear online documentation, but I can't determine what I would think were some fairly obvious questions: What's the step by step process for syncing files with JPilot? Can I install .prc files with gpilot? Is there a relationship between JPilot and Gpilot, or are they two programs for the same task?
Dave
On Mon, 2005-09-05 at 23:06 +0900, Dave Gutteridge wrote:
I meant the palm pilot - making sure it is set to 57600 and auto-flow
Oh, I see. Yes, the Palm Pilot is set to 57600 and automatic flow.
yes - and the usb drivers - try the windows fix - reboot the system.
System rebooted, and yet still it's coming up with the same error. However, now that you've convinced me that it's probably not a permissions issue, I've been wondering if maybe I'm just not understanding the set up. For example, I thought gpilot was necessary in order to have connection to the Palm Pilot. But should I be running either Jpilot or Gpilot, or both? Also, what I've determined about Jpilot is that the error comes up before I hit the sync button on the Pilot. But then when I hit the sync pilot on the Pilot, and return to JPilot, it can't find the Pilot. I've tried finding clear online documentation, but I can't determine what I would think were some fairly obvious questions: What's the step by step process for syncing files with JPilot? Can I install .prc files with gpilot? Is there a relationship between JPilot and Gpilot, or are they two programs for the same task?
----- jpilot and gpilot are completely different programs and they share nothing but probably the symbolic link to /dev/pilot and that's it.
if you want to check out raw transfer with gpilotd...
from cli...(probably as user and not root)
pilot-xfer -p /dev/pilot -L #and then press the hotsync/cradle or palm
see if it connects, backs up, etc.
if you have no data at all in jpilot...
rm -fr $HOME/.jpilot
then start the program as this will flush the settings and return to defaults.
if you have data in jpilot...you could mv instead of rm
cd $HOME mv .jpilot .jpilot-bak
All sorts of programs can install prc (palm programs) including gpilot (gnome-pilot). JPilot should be the easiest to get working though.
Thus you can run both or either gpilot/jpilot as they have nothing really to do with each other.
Craig
jpilot and gpilot are completely different programs and they share nothing but probably the symbolic link to /dev/pilot and that's it.
I see. Thank you for clearing that up.
After completely halting gpilot and rebooting and various attempts at finding the right order of pressing which sync button at which time, something has finally changed. The error no longer comes up, and if I press the sync on the Palm first, and then the sync button in JPilot second, I can successfully sync between them.
I appreciate you and the other members of the list walking me through this and getting it to work.
Dave
On Tue, 2005-09-06 at 23:10 +0900, Dave Gutteridge wrote:
jpilot and gpilot are completely different programs and they share nothing but probably the symbolic link to /dev/pilot and that's it.
I see. Thank you for clearing that up.
After completely halting gpilot and rebooting and various attempts at finding the right order of pressing which sync button at which time, something has finally changed. The error no longer comes up, and if I press the sync on the Palm first, and then the sync button in JPilot second, I can successfully sync between them.
I appreciate you and the other members of the list walking me through this and getting it to work.
---- This should be instructive to you that it is not generally necessary to brute force things such as permissions. You should have faith that the developers are quite intelligent on these things and what holds us back (and I definitely include myself here), is the lack of understanding of how things work. As you can see though, when you figure them out, it even makes Windows more understandable.
Now - gpilotd is a daemon and when running, will monitor the port that it is set to monitor...typically /dev/pilot
Thus if gpilotd is working properly, all you should need to do is press the hotsync button on the cradle or in the palm environment.
jpilot might have some similar daemon - I don't know - I never persisted in using jpilot but without that daemon to monitor for the presence of /dev/pilot, jpilot only complains that there is no /dev/pilot when told to sync with the palm before you press hotsync on the palm or cradle.
Craig
This should be instructive to you that it is not generally necessary to brute force things such as permissions. You should have faith that the developers are quite intelligent on these things and what holds us back (and I definitely include myself here), is the lack of understanding of how things work.
Well, I'm not really sure that description represents the situation. I didn't just make up the issue of permissions. In fact, I don't know nearly enough about Linux to even conceive of a solution like that. What I got was an error message, with the word "ERROR" in capital letters, and I looked it up on the net. I really can't see how that's an unreasonable course of action.
Following that, after I came across a suggestion that it was a permissions problem, I came here to this list to ask further, and I wasn't told right away "no, that's not a permissions issue, that's a different problem". I was told how to possibly modify permissions, and got kind of deep into it before someone finally said "hey, maybe it's not a permissions problem". So for a while I had a lot of support for the idea that it was a permissions problem.
In other words, faith doesn't enter into it. My understanding of Linux is only as good as the information I find in response to my queries.
I'm not sure how far I would get if I always assumed I was just doing things wrong every time I came across an error message. I've worked with computers long enough to know that an error is quite likely to actually be an error.
Dave
On Wed, 2005-09-07 at 00:16 +0900, Dave Gutteridge wrote:
This should be instructive to you that it is not generally necessary to brute force things such as permissions. You should have faith that the developers are quite intelligent on these things and what holds us back (and I definitely include myself here), is the lack of understanding of how things work.
Well, I'm not really sure that description represents the situation. I didn't just make up the issue of permissions. In fact, I don't know nearly enough about Linux to even conceive of a solution like that. What I got was an error message, with the word "ERROR" in capital letters, and I looked it up on the net. I really can't see how that's an unreasonable course of action.
Following that, after I came across a suggestion that it was a permissions problem, I came here to this list to ask further, and I wasn't told right away "no, that's not a permissions issue, that's a different problem". I was told how to possibly modify permissions, and got kind of deep into it before someone finally said "hey, maybe it's not a permissions problem". So for a while I had a lot of support for the idea that it was a permissions problem.
In other words, faith doesn't enter into it. My understanding of Linux is only as good as the information I find in response to my queries.
I'm not sure how far I would get if I always assumed I was just doing things wrong every time I came across an error message. I've worked with computers long enough to know that an error is quite likely to actually be an error.
---- the thread was titled changing permissions
my first 2 answers to this question made it clear that this was udev stuff and not permissions - not console.perms - not at all related to the issues raised in the link you provided with talked about RH 8.0
The only support you got regarding permissions was because you directed everyone's attention to permissions and I can't help the fact that people trying to be helpful in answering your permissions questions misdirected you by not realizing that your questions about permissions didn't have anything to do with your problem. You framed the issue - I had to redirect your energy away from thinking that it was a permissions problem.
I think most people recognize that you spend a lot of effort trying to solve your issues and try to help out because of that.
Craig
Please don't take this personal, as I respect and understand your help, and that of everyone else on this list.
But I'm really not sure where you're going by talking of how I framed this discussion around permissions. Somehow you seem to be implying that I was looking for a particular kind of solution on my terms, or that to have asked about permissions in the first place was somehow a flawed approach.
Before I we get too deep into a "you said, I said" debate, all I'm trying to say was that I would not, and I doubt most normal newbies, try to steer a thread in any direction, regardless of it's starting point. I have no particular preference for any kind of solution, other than ones that work, regardless of how the solution is reached.
Whenever I come across a problem, I do my best to search the net for solutions so that I can hopefully answer them myself, or, failing that, to phrase my question in the most sensible way possible. I will always try to give my questions a context so that I am not just saying "it's not working, tell me what to do".
That approach will always give my thread a starting framework. If there is a better approach to asking questions on this list, please let me know what that is.
Dave
On Sun, 2005-09-04 at 12:30 +0900, Dave Gutteridge wrote:
If you look at the above - it already is usable (in fact owned) by the user dave.
Well, if you say so, I believe you. The reason I think I don't have the correct permissions settings is because on the following web page, it says that the error I get is because the permissions are wrong. If I already have the "correct" permissions settings, and I still get this error, then I'm at a loss to diagnose the problem. http://www.brandonhutchinson.com/Running_JPilot_as_a_non-privileged_user.htm...
---- that was probably good advice for Red Hat 8.0 and 2.4 kernel ----
make sure that 'jpilot' or any other program that you wish to use to sync your Palm, uses /dev/pilot
In the JPilot preferences page, it has a field for entering in "Serial Port". In that field I have "/dev/pilot". There does not seem to be an option or way to specify whether or not the connection is USB, but I assume if it's going to /dev/pilot then it should be looking in the right place...?
---- look again at the output of 'ls -l /dev/pilot /dev/ttyUSB*'
if you are syncing, /dev/pilot is a symbolic link to /dev/ttyUSB1
what more do you think that you need?
Craig
-
Craig White -
Dave Gutteridge -
Ignacio Vazquez-Abrams -
Johnny Hughes -
Sean O'Connell