mhttpd odb editor page confused by symlinks to symlinks

[dd1]

the mhttpd odb editor page is confused by symlinks pointing to symlinks, for example, create an integer called "/test/int", create a symlink to it "/test/link" -> "/test/int", and a symlink to the symlink: "/test/link2" -> "/test/link". Maybe you will see the value of "/test/link2" correctly, (same as "/test/int"). Now try to edit it, you will be offered to edit the symlink itself, not the value. There are other oddities (play with it). Also try symlinks to symlinks that point to subdirectories. K.O.

[Stefan Ritt]

Uh, tricky. I never thought about symlinks to symlinks. Actually this feature never worked because it was never implemented.

I changed now db_find_key to resolve links recursively to any depth, and this apparently fixed the reported problem. I also tried symlinks to symlinks to subdirectories, and it worked for me. But further testing might be necessary. I'm not sure if this modification breaks something else.

I tried to make symlinks in a circular way (L1 -> L2 and L2 -> L1) and this was not possible in odbedit. I could do it however with the web interface and indeed that caused an endless loop inside db_find_key() with a stack overflow in the end. I don't have a clever idea of how to avoid such stupidities. One could add a recursion level to db_find_key(), but that needs an extra (hidden) parameter with changes all over the place (what if you have a new client and an old mserver program). So I count on peoples common sense not to make links in circles...

/Stefan

[dd1]

odbedit also does the wrong thing with "link to link". This is before your fix - I will retest with the fix. K.O.

[dd1]

regarding symlink loops - UNIX always had a hardwired limit on the maximum number of symlinks - google MAXSYMLINKS. I vote that we do the same thing. K.O.

[dd1]

retested with your fix - do not see any anomalies - all looks good. K.O.