[rrd-developers] Bug#497739: rrdtool: rrdgraph no longer drops all directories given in filename argument when imginfo string prints

[Sebastian Harl]

Hi Tobi,

On Thu, Sep 04, 2008 at 11:42:46AM +0200, Tobias Oetiker wrote:
> Today Sebastian Harl wrote:
> > (This is a follow-up to Debian bug #497739. See [1] for more details.)
> >
> > [1] http://bugs.debian.org/497739
> >
> > On Wed, Sep 03, 2008 at 03:57:54PM -0700, bardia wrote:
> > > I'm using rrdcgi from rrdtool to plot sensor data on my website via the sensord
> > > generating rrdcgi script.  The printed "IMG SRC" path is now broken b/c the
> > > directories in the filename path aren't being pruned.  The expected behavior of
> > > rrdgraph is mentioned in the rrdcgi man page but not in the rrdgraph man page.
> > >
> > > Below is an example rrd line from the rrdcgi script that i pulled out to run
> > > directly on the command line using two different versions of rrdtool:
> > >
> > > !!**command line:
> > > rrdtool graph /var/www/sensors/pics/castledaily-temperature.png --imginfo '<IMG SRC=/sensors/pics/%s WIDTH=%lu HEIGHT=%lu>' -a PNG -h 200 -w 800 --lazy -v 'Temperature (C)' -t 'Temperature' -x 'HOUR:1:HOUR:3:HOUR:3:0:%b %d %H:00' -s -1d -l 0 DEF:temp1=/var/www/sensors/data/castle.rrd:temp1:AVERAGE DEF:temp1_0=/var/www/sensors/data/castle.rrd:temp1_0:AVERAGE DEF:temp2=/var/www/sensors/data/castle.rrd:temp2:AVERAGE DEF:loadavg=/var/www/sensors/data/castle.rrd:loadavg:AVERAGE LINE2:temp1#6e980e:"Core0 Temp" LINE2:temp1_0#aff9e7:"M/B Temp" LINE2:temp2#8897c8:"CPU Temp" LINE2:loadavg#7cfcce:"Load Average"
> > >
> > > !!** _GOOD_ output (rrdtool version 1.2.27-2):
> > > <IMG SRC=/sensors/pics/castledaily-temperature.png WIDTH=897 HEIGHT=279>
> > >
> > > !!** _BAD_ output (rrdtool version 1.3.1-3):
> > > <IMG SRC=/sensors/pics//var/www/sensors/pics/castledaily-temperature.png WIDTH=897 HEIGHT=274>
> > >
> > > There are easy ways to workaround this problem aside from reverting to ver 1.2,
> > > e.g., string replacement, so i'm too lazy to look at the sources and submit a
> > > patch, sorry.
> >
> > I'm not sure about the behavior intended by upstream and the motivation
> > for changing it from 1.2 to 1.3. With this message, I've forwarded the
> > bug the upstream developers mailing list, hoping for a comment.
> 
> it is a bug ... fixed in svn ...

FTR: The fix can be found in r1459 and should be included in 1.3.2.

The patch is searching backwards through the filename looking the
beginning of the filename:

+        while(filename > im.graphfile) {
+            if (*(filename-1)=='/' || *(filename-1)=='\\' ) break;
+            filename--;
+        }

What I don't understand though is why '\\' is supposed to mark the
beginning of the filename. Tobi, is that supposed to take care of
Windows? In theory, '\\' may be used in filenames on Unix systems, so
this might behave incorrectly then. Is there any reason why you don't
use the basename(3) function instead? That's defined in POSIX.1-2001 (as
an XSI extension), so it should not cause any problems.

TIA,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20081104/90b663a8/attachment.bin