saving symlinked trac.ini through web_ui clobbers symlink

[lkraav <leho@…>]

i have consolidated all my trac.ini files into a single revision controlled directory and symlinked to them from each respective project's conf/ directory.

every once in a while i forget this problem exists and save some setting (i.e. enable/disable plugins) through web interface. this results in conf/trac.ini symlink being replaced by a new copy conf/trac.ini file. this means making changes to my central .ini-repository will have no effect on the project env because the symlink is gone and it might take a while to even notice that.

expected behavior would be for the symlink to remain intact.

[lkraav <leho@…>]

fix summary typo

[Remy Blank]

This is due to the way we update trac.ini atomically, by writing to a temporary file and moving over the current file. This avoids corrupting trac.ini if it is modified concurrently.

Why do you go to all the trouble of moving the configurations to some place, and put symlinks in the environments to point back to the files? You could just put the environments themselves under version control (with suitable ignores), and actually, that's how I do it.

I assume you never have two environments that point to the same file? We could use realpath() to find the location of the file, then replace that instead of the symlink, but I'm not sure this is desired in all cases. Thoughts?

[lkraav <leho@…>]

good point i guess re: having parent_env_dir revision controlled instead of just configuration files, basically it's some legacy situation here. i have no case where two environments point to the same configuration file. if there's a symlink made by the admin, i don't immediately see how it should be trac's responsibility to figure out anything beyond basic symlink-logic.

[Remy Blank]

Replying to lkraav <leho@…>:

if there's a symlink made by the admin, i don't immediately see how it should be trac's responsibility to figure out anything beyond basic symlink-logic.

So, what do you suggest? If it's not a common situation, I'd rather close as "wontfix" rather than make the code more complex.

[Christian Boos]

Let's just keep the status quo here.