[Bitpim-devel] Re: [bitpim-cvs-checkins] bitpim com_samsung.py,1.9,1.10

[Roger Binns]

It's "True", not "Truth".

Very deeply philosophical :-)

Roger

[Vic Heintz]

It seems that the _get_phonebook routine was probably doing what it was
supposed to do.

After some investigation I discovered that I had some corrupted
phonebook entries from prior uses of "Save Phone Data" (which is
obviously is of great concern.) The first clue was that my voicemail
phone number was swapped with my daughter's cell phone number and vice
versa. Her number was showing up on the phone but not in bitpim.
Likewise another phone entry was showing up on the phone and not in
bitpim but appeared to have correct phone numbers. These apparently had
bogus entry IDs but contributed to the count PCBIT was returning. So
the routine was never finding them. (Perhaps the loop was not truly
endless and would have found them before hitting an astronomical number
like 32767 if I had let it go.)

When I edited my voicemail number back to *86 I got no complaint. When
I tried to edit my daughter's cell phone number from *86 back to her
correct one. The phone complained that the number was already saved at
location X. When I looked at location X there was no such number.
However, deleting the entire entry assigned to location X allowed me to
edit my daughter's number. I made a token edit on the other entry which
wasn't showing up in bitpim and the entire problem was cleared up.

I don't know if it is significant but this latter entry was maxed out
and truncated in the name field. I had imported this from a vCard where
it had more characters than is allowed for the name field on the
samsung a670. I would not be surprised if there were some sort of
overflow error during the Send operation which caused my phonebook
corruption.

Vic

[Vic Heintz]

Post by Vic Heintz
I don't know if it is significant but this latter entry was maxed out
and truncated in the name field. I had imported this from a vCard
where it had more characters than is allowed for the name field on the
samsung a670. I would not be surprised if there were some sort of
overflow error during the Send operation which caused my phonebook
corruption.

I just confirmed using Kermit that AT#PBOKW does NOT produce an error
if a string longer than the allowed 22 chars is sent for the name
field. It happily writes away and returns OK. It had the effect that
the phone then showed two entries with the same name truncated to 22
chars. All of the info in each seemed to be the same including the
assigned speed dial location. Erasing one leaves the other but it is
empty. I wasn't able to delete the empty record at this point. Turning
the phone off and on again seems to have restored the phonebook to
normal. I hope.

It is clearly important that the send routine checks the validity of
the data first.

Vic

[d***@netzero.com]

Vic, thanks for pointing that out. I'll add the checks to the code.

-Joe Pham

Post by Vic Heintz
I don't know if it is significant but this latter entry was maxed out
and truncated in the name field. I had imported this from a vCard
where it had more characters than is allowed for the name field on the
samsung a670. I would not be surprised if there were some sort of
overflow error during the Send operation which caused my phonebook
corruption.

I just confirmed using Kermit that AT#PBOKW does NOT produce an error
if a string longer than the allowed 22 chars is sent for the name
field. It happily writes away and returns OK. It had the effect that
the phone then showed two entries with the same name truncated to 22
chars. All of the info in each seemed to be the same including the
assigned speed dial location. Erasing one leaves the other but it is
empty. I wasn't able to delete the empty record at this point. Turning
the phone off and on again seems to have restored the phonebook to
normal. I hope.

It is clearly important that the send routine checks the validity of
the data first.

Vic



-------------------------------------------------------
This Newsletter Sponsored by: Macrovision
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
_______________________________________________
Bitpim-devel mailing list
Bitpim-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitpim-devel


________________________________________________________________
Speed up your surfing with NetZero HiSpeed.
Now includes pop-up blocker!
Only $14.95/ month - visit http://www.netzero.com/surf to sign up today!

[Vic Heintz]

If you look at examples/samsungnotes.txt the allowed ranges are found
here:
AT#PBOKR=?
#PBOKR: (1-500),(0-4),22,32,48,0
1-500 is the range of entries and speed-dials
0-4 is presumably the range of group IDs
22 is allowed characters in Name
32 is allowed digits in phone numbers
48 is allowed chars for email and alias

For the contact image field (last one before timestamp) on the a670 and
a610 there should be no more than 20 chars when this is selected on the
phone from the gallery because the paths will look like:
"digital_cam/Image025"

Vic

Post by d***@netzero.com
Vic, thanks for pointing that out. I'll add the checks to the code.
-Joe Pham

Post by Vic Heintz
I don't know if it is significant but this latter entry was maxed out
and truncated in the name field. I had imported this from a vCard
where it had more characters than is allowed for the name field on the
samsung a670. I would not be surprised if there were some sort of
overflow error during the Send operation which caused my phonebook
corruption.

I just confirmed using Kermit that AT#PBOKW does NOT produce an error
if a string longer than the allowed 22 chars is sent for the name
field. It happily writes away and returns OK. It had the effect that
the phone then showed two entries with the same name truncated to 22
chars. All of the info in each seemed to be the same including the
assigned speed dial location. Erasing one leaves the other but it is
empty. I wasn't able to delete the empty record at this point. Turning
the phone off and on again seems to have restored the phonebook to
normal. I hope.
It is clearly important that the send routine checks the validity of
the data first.
Vic
-------------------------------------------------------
This Newsletter Sponsored by: Macrovision
For reliable Linux application installations, use the industry's
leading
setup authoring tool, InstallShield X. Learn more and evaluate
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
_______________________________________________
Bitpim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel
________________________________________________________________
Speed up your surfing with NetZero HiSpeed.
Now includes pop-up blocker!
Only $14.95/ month - visit http://www.netzero.com/surf to sign up
today!
-------------------------------------------------------
This Newsletter Sponsored by: Macrovision
For reliable Linux application installations, use the industry's
leading
setup authoring tool, InstallShield X. Learn more and evaluate
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
_______________________________________________
Bitpim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel