SquirrelMail version 1.4.4
The problem occurs if you use the preference database
(instead of files) and users have folders / subfolders
longer than 64 characters.
In this case collapsing a folder in Squirrelmail will
lead to the following error message:
Preference database error (unknown error). Exiting
abnormally
This is caused by the prefkey field in the database
being only 64 characters long. In the case described
above, Squirrelmail tries to insert into the prefkey
field a longer value (collapse_folder_<folderList>).
Logged In: YES
user_id=620333
The examples in the docs are just that, examples. You can
easily modify the database design to meet your needs, for
example, expand the width of the prefkey field. I don't
believe there would be any way around this programatically,
the best we can do is update the doc to tell people the
values are examples, and can be adjusted to suite your
environment.
Logged In: YES
user_id=225877
Backend might silently ignore option, if preference key
length exceeds max field size. Such preferences will stay
only in current session. Max size can be hardcoded in
backend library or set in configuration.
We can also display some error notices. Main issue - current
preference layout and setPref function are not designed to
handle errors. Code just fires setPref and expects that
backend will handle errors. setPref can be called before
page header is displayed, after page header or before
redirection to other page. Code might be running in any
gettext domain.
I think backend could make sure that it is running in
squirrelmail gettext domain, call error_box() function and
stop script execution.
In this case ignoring long keys is less intrusive, but can
cause "setting is not saved" bug reports.
Logged In: YES
user_id=225877
Name and version of used database server?
Name and version of used php db libraries?
Used Pear-DB version?
Can't reproduce it in MySQL server 4.1.11, MySQL client
4.0.24 and Pear DB 1.6.2. SquirrelMail 1.5.1cvs and 1.4.5.
System truncates oversized fields without any error messages.
Logged In: YES
user_id=620333
Postfix might be a little more snippy about the lengths of
data being inserted. I know MS SQL has a fit about it too,
it generates an error "binary or string data will be
truncated" and stops.
Logged In: YES
user_id=620333
That should have been postgresql rather than postfix.
Logged In: YES
user_id=225877
Should be solved in 1.5.1cvs