[gobolinux-devel] "backlinked" variable revisited

[Jonas Karlsson]

Ok, I have to bring up this issue once more, as I've found out that  
there's a problem with union sandbox as well and no real solution was  
decided on last time this issue was up.

With fibo sandbox: when 'make install' tries to place a file or make a  
directory in /Programs/Foo/Variable, when there already exist some  
structure, it is bound to fail as the user fibo doesn't have permissions  
outside the sandbox, more precisely in /System/Variable, where links from  
/Programs/Foo/Variable points to.

With union sandbox: this is only a problem when 'make install' tries to  
create a directory, which an earlier version of Foo created and therefore  
exists as a link. For example, I tried to recompile HTTPD 2.2.3, because  
I'm making a new revision and want to try the recipe, and 'make install'  
wants to create the directory /Programs/HTTPD/Variable/run/httpd. As this  
directory was created last time I compiled httpd 2.2.x, and the fact that  
'run' is expanded, 'httpd' is a link pointing at  
/System/Variable/run/httpd. This isn't strange, but even though fibo has  
write permissions though union sandbox, it can't create the directory,  
because there's already a file (or a link rather) with the exact same name  
- and the install dies (this would be a problem for fibo sandbox as well,  
if the first problem is solved by giving fibo write rights in  
/System/Variable).

I don't like to handle variable as unmanaged files. I like the fact that  
there exist a point (/Programs/Foo/Variable) where one can see the  
contents of what Foo has. What about making it a bit more like Settings,  
i.e. all write to /Programs/Foo/Variable are redirected (either with  
symlink in fibo sandbox or with union mount with union sandbox) to  
Resources/Defaults/Variable and then /Programs/Foo/Variable is updated  
with the new contents (this update is much easier then the Settings  
update, as new files are created, no files are merged and old files are  
kept). We should still use the "backlinked" solution, as I like that the  
var bulk should be stored in /System/Variable, not spread in different  
folders under /Programs, and SymlinkProgram could handle this (to move the  
files and to create the symlinks), but now we can handle any conflict  
manually, like write permissions, file exists etc.

-- 
/Jonas

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/