View Ticket
Not logged in
Ticket UUID: c3971eac71a1bd01cc2e47b8c1f2d109b54d5574
Title: fossil breaks if HOME points to read-only directory
Status: Open Type: Code_Defect
Severity: Minor Priority: Medium
Subsystem: Resolution: Open
Last Modified: 2010-10-06 12:35:15
Version Found In: [7c37b46b12] 2010-04-15 23:53:15 UTC, [528c581154] 2010-09-28 18:40:01 UTC
Description & Comments:
Try the following:
export HOME=/
cd /tmp
fossil new test.fossil

The following message is produced:

fossil: SQLITE_CANTOPEN: cannot open file at source line 26294
fossil: unable to open database file

If you have recently updated your fossil executable, you might need to run "fossil all rebuild" to bring the repository schemas up to date.

This example assumes that the logged in user does not have write access to / but does have write access to /tmp. This is a contrived example that demonstrates the problem; the actual problem was encountered while attempting to use fossil when running as another user (via sudo), but with the old value of HOME (the default sudo behavior of preserving the original environment).

If instead HOME points to another user's directory that has a .fossil, but the current user does not have write access to it and you attempt to clone (instead of just new) you get:

fossil: SQLITE_READONLY: statement aborts at 19: [INSERT OR IGNORE INTO 
global_config(name,value)VALUES('repo:/tmp/foo.fos',1)] attempt to write a readonly database
fossil: attempt to write a readonly database
INSERT OR IGNORE INTO global_config(name,value)VALUES('repo:/tmp/foo.fos',1)

If you have recently updated your fossil executable, you might
need to run "fossil all rebuild" to bring the repository
schemas up to date.
fossil: SQLITE_ERROR: statement aborts at 2: [ROLLBACK] cannot rollback - no transaction is active

I was expecting fossil to work whether or not it can muck around with ~/.fossil. vim works whether or not it can write to ~/.viminfo (although it does complain if it can't).


anonymous added on 2010-10-06 12:35:15:
This also happens when using "sudo" to impersonate another user, because "sudo" doesn't change the HOME variable like "su" does. I have just encountered this on Ubuntu Lucid 32-bit. I am using fossil version [528c581154] 2010-09-28 18:40:01 UTC.

buildbot@nikko:/var/lib/buildbot/Reu2/slave/bin/nikko/build$ fossil clone http://fatman@dreamtrack.dnsalias.com/fossils/reu2.cgi/reu2 ./reu2.fossil
fossil: home directory /home/fatman must be writeable

Regards, Adam J Richardson