[fossil-users] fossil silently ignores capitalized ticket table field names
I spent a couple hours hunting for a bug in which fossil does not properly
apply changes to my custom fields to the ticket table. The root cause
appears to be these lines from cgi.c's add_param_list():
if( fossil_islower(zName[0]) ){
cgi_set_parameter_nocopy(zName, zValue);
}
... i.e. silently ignore capitalized POST argument names. Is there a
reason for that?
It appears to have been like that since the very first check-in of the
file. I can't possibly be the only person in six years to have been hit by
this.
Fossil should have rejected my attempt to create capitalized ticket table
column names if it was planning on ignoring edits to those fields later.
And it should warn me on the ticket table edit page that capitalized names
do not work.
Or, better, it should just allow capitalized ticket table column names.
Also, I managed to hose my repo by changing my ticket column names from
upper case to lower case, hoping that fossil would have some heuristics to
carry my data over, or else would warn me that it was going to blow away my
values. I hoped in vain. There should be a warning about that, too.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil silently ignores capitalized ticket table field names
On Tue, Aug 6, 2013 at 4:31 PM, Eric Rubin-Smith eas@gmail.com wrote:
I spent a couple hours hunting for a bug in which fossil does not properly
apply changes to my custom fields to the ticket table. The root cause
appears to be these lines from cgi.c's add_param_list():
if( fossil_islower(zName[0]) ){
cgi_set_parameter_nocopy(zName, zValue);
}
... i.e. silently ignore capitalized POST argument names. Is there a
reason for that?
Yes there is.
Fossil combines inputs from a number of different sources into a single
namespace:
(1) CGI Environment Variables
(2) URL query parameters
(3) POST parameters in the HTTP request payload
(4) Cookie values
Internally, the Fossil C code accesses the parameter using the
cgi_parameter(zName, zDefault) function. This function is so commonly used
that special macros are defined to make it easier to type:
#define P(X) cgi_parameter((X),0)
#define PD(X,Y) cgi_parameter((X),(Y))
So if the code needs to know the value of CGI environment variable
REMOTE_USER it runs P(REMOTE_USER). Or to find the value of the uuid
query parameter, it runs P(uuid). And so forth. Note that when the code
asks for the value of uuid, it does not know nor care if that is a query
parameter, a POST parameter, or a cookie.
In order to prevent a cookie, query parameter, or POST parameter from
overriding a CGI environment variable (which would be a very serious
security vulnerability) the names of cookies, query parameters and POST
parameters are required to begin with a lower-case letter.
It would certainly be possible to invent a less-restrictive rule that
allowed for some upper-case POST and query parameters and cookies as long
as they do not collide with environment variable names. But the current
rule (no upper-case except for environment variables) is simple and
effective.
It appears to have been like that since the very first check-in of the
file. I can't possibly be the only person in six years to have been hit by
this.
Fossil should have rejected my attempt to create capitalized ticket table
column names if it was planning on ignoring edits to those fields later.
And it should warn me on the ticket table edit page that capitalized names
do not work.
Or, better, it should just allow capitalized ticket table column names.
Also, I managed to hose my repo by changing my ticket column names from
upper case to lower case, hoping that fossil would have some heuristics to
carry my data over, or else would warn me that it was going to blow away my
values. I hoped in vain. There should be a warning about that, too.
No information is lost when you change your ticket table definition. To
recover, just change the ticket table schema back and it will be
repopulated to exactly what it contained before. The ticket table itself
is just a cache for the contents of the ticket-change artifacts, and those
artifacts are immutable. Whenever you change the ticket table schema,
Fossil automatically rebuilds the cache. It is not possible to lose
information this way.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil silently ignores capitalized ticket table field names
... i.e. silently ignore capitalized POST argument names. Is there a reason for that? Yes there is. Thanks Richard. So I was initially planning on doing a brute-force migration to the new ticket table schema with the lowercase letters. But it sounds like that is a pointless exercise, since the real point of truth is the artifacts (and I should have known that, since I read all your start-up docs). So I guess I have two options: * Blow out all the artifacts into a directory, munge them to have the new column names, and then rebuild the database from the munged artifacts. * Generate new artifacts indicating additions of tags that are the new column names. Leave the old tags alone, and just adjust the ticket view and edit pages' code. I assume you will find the former distasteful and will recommend the latter. Any easy way to accomplish that, or should I start hacking up a script? Thanks, Eric ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil silently ignores capitalized ticket table field names
On Tue, Aug 6, 2013 at 5:27 PM, Eric Rubin-Smith eas@gmail.com wrote: ... i.e. silently ignore capitalized POST argument names. Is there a reason for that? Yes there is. Thanks Richard. So I was initially planning on doing a brute-force migration to the new ticket table schema with the lowercase letters. But it sounds like that is a pointless exercise, since the real point of truth is the artifacts (and I should have known that, since I read all your start-up docs). So I guess I have two options: * Blow out all the artifacts into a directory, munge them to have the new column names, and then rebuild the database from the munged artifacts. * Generate new artifacts indicating additions of tags that are the new column names. Leave the old tags alone, and just adjust the ticket view and edit pages' code. I assume you will find the former distasteful and will recommend the latter. Any easy way to accomplish that, or should I start hacking up a script? I have no recommendation one way or the other. Use whichever approach seems to work best for you. There are no tools in Fossil that I recall that will help with this. I think you need a script. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
