[NB. this bug should be tagged against both gmetad and web frontend]

Both gmetad and web-frontend use the metric name appended with ".rrd" as the 
filename for the RRD storage file.

Under Linux VFS (probably other OSes too), filenames with the '/' (slash) 
character are not allowed.  This causes any metric with a '/' in the metric's 
name to fail.

Simple test-case:
  gmetric -nTest/test/test -v53 -tuint32
  telnet gmetad-host.example.org 8649 > /tmp/gmetad-out.xml
  grep Test/test/test /tmp/gmetad-out.xml
  ssh gmetad-host.example.org 'find /var/lib/ganglia/rrds -name \*Test\*'

A fix is available here:
  http://ppewww.ph.gla.ac.uk/~paul/ganglia-slash-fix.diff

The fix is to escape any "/" characters.  Other characters may be illegal under 
different OSes.  This method can be easily extended to allow full functionality 
under other OSes.

An alternative approach would be to hash the metric and used some encoding 
(Base64, say) of the filename-hash as the filename.  This would be guaranteed 
OK, but would loose the nice filenames.

Created an attachment (id=40) [details]
Patch to fix the problem

Proposed fix (from above URL).

Created an attachment (id=58) [details]
enhanced version of previous patch

This is a modified version of the previous patch.
It now:
  uses the standard markup ( `%' <hex-digit> <hex-digit>)
  supports multiple OSes with different reserved characters

Hi Paul:

I am trying to apply the enhanced version of the patch to branch-3.0.x -- I
noticed that BSD is not in the switch for rrdfilename function -- would that
potentially break compatibility?

Thanks,

Bernard

Waiting for re-base to ganglia trunk.

Created an attachment (id=83) [details]
Latest version of patch, good for current trunk

This is a new version of the patch, rebased against current trunk.  Nothing of
substance has changed: the previous patch applied with one hunk needing a small
fuzz.

I've taken the opportunity to adjust the comments slightly.  There's now
comments linking the C- and PHP- markup functions.  Also, I've removed one of
the TODO items: the corner-case of supporting the VFAT limitations for VFAT-fs
mounted under Linux VFS turns out not to be a problem.

Full RFC2396 encoding seems overkill, as the problem will only require
filesystem encoding and a way for the frontend to translate a metric using that
when needed.

Hi Carlo,

Please review the patch.  I think it does what you propose; specifically,
it "marks up" only those characters that cannot be expressed by a specific
filesystem (and '%').

For Linux VFS, the only forbidden character (other than nul, '\0') is the
forward-slash ('/').  So, on Linux machines, only metrics that include this
character (or '%') are marked up in the filename.

RFC-2396 describes a common method of marking up characters.  Since it's a
standard (of sorts) and widely used, it makes sense to use it here, too.

A side-effect of adopting this markup is that all '%' characters must also be
marked up.  However, this is in common with all other markup schemes: they all
require a "special" character that must be marked up, too.

My original patch included an alternative markup scheme because I
(erroneously) believed '%' was an illegal character on certain systems.  This
turns out not to be the case.

Adopting RFC-2396's method of marking up was done due to feedback from other 
Ganglia developers.  It's also adopting an existing standard and the code to 
do this is already written and tested, so I'm reluctant to change the markup 
to yet a third scheme.

Does that make sense?

Cheers,

Paul.

This issue was raised nearly 5 years ago, has it been fixed yet?  I am still
unable to use '/' in my metric names.