Problems with symbolic links in /Alias ODB tree

Issue #153 resolved
Devin Connolly created an issue

When attempting to create a symbolic link (test) in the /Alias ODB tree (via odbedit as described here, the link is created however, when clicking the link on the mhttpd side navigation, one receives

Error: cannot find key Alias/[object Object]

If running mhttpd interactively with verbose output, the lines following clicking the sidenav link are:

handle_http_get: uri [/[object Object]], query []
handle_http_get: uri [/mhttpd.css], query []
handle_http_get: uri [/midas.css], query []
handle_http_get: uri [/obsolete.js], query []

On the other hand, navigating to /Alias and clicking the link results in the expected behavior, and the mhttpd interactive output is as follows:

handle_http_post: uri [/Alias], query [mjsonrpc], post data 401 bytes
handle_http_post: uri [/], query [mjsonrpc], post data 178 bytes
handle_http_get: uri [/Alias/test], query []
handle_http_get: uri [/Alias/mhttpd.css], query []
handle_http_get: uri [/Alias/midas.css], query []
handle_http_get: uri [/Alias/obsolete.js], query []
handle_http_get: uri [/Alias/mhttpd.js], query []
handle_http_get: uri [/Alias/controls.js], query []
handle_http_get: uri [/Alias/midas.js], query []
handle_http_post: uri [/Alias/test], query [mjsonrpc], post data 199 bytes
handle_http_post: uri [/Alias/test], query [mjsonrpc], post data 401 bytes

Also, attempting to create a link in the /Alias tree via odbedit by doing

create link test
set test /Experiment

results in Error: Key "/Alias/test" not found despite the fact that the link exists (although it is empty, as evidenced by ls). This is soon followed by mhttpd crashing with the following error:

mjsonrpc_error_alert: network error: see javascript console, 
method: "db_get_values", params: [object Object], id: 1536869171516

If running mhttpd interactively with verbose output, the lines following the crash are (on OS X 10.8.5 - Mountain Lion):

handle_http_post: uri [/Alias], query [mjsonrpc], post data 199 bytes
Bus error: 10 (core dumped)

On CentOS 7.5.1804, the mhttpd verbose output is slightly more helpful:

handle_http_post: uri [/Alias], query [mjsonrpc], post data 199 bytes
mhttpd: src/odb.c:8158: json_write: Assertion `remain >= 0' failed.
Aborted (core dumped)

Attempts to restart mhttpd result in similar crashes until the offending link is deleted.

Attempting to create the link via the webpage by clicking the Create button and selecting type: Symbolic Link results in the (empty) link being created, but attempting to set the link by clicking on its value results in mhttpd crashing with the aforementioned error and behavior.

If instead, the link is created as a string and its value is set to the desired ODB path, the link on the mhttpd side navigation works.

This is on a Mac running OSX 10.8.5 (Mountain Lion), but I was able to duplicate identical behavior on CentOS 7.5.1804.

Comments (6)

  1. Stefan Ritt

    When I create a link as a string, everything works. To make ODB links to work, we have to extend the JSON-RPC interface, adding a db_get_link() call to replace the db_get_values() which follows links. Something for the to-do list, but no time for it right now. By adding strings you have at least a working system right now. If we do not need ODB links there, we can also adjust the documentation to tell users not to create links but strings ala:

    > cd /Alias
    > cr string test
    String length [32]: 256
    > set test /path/to/odb/subtree
    
  2. dd1

    I think Stefan tried to replicate the wrong problem. You are trying to use an "alias to odb" which uses a kludge of creating bogus symlinks under /alias. I do not think this function currently works (I did not know it existed).

    Simplest solution is to replace it with something called "/odbalias" which would have a bunch of string entries corresponding, one per aliased odb entry. the string name would show up on the web page, the string contents would be the odb path.

    Trying to use odb symlinks as a "special type of string" is just wrong, I think.

    K.O.

  3. Log in to comment