pureftpd creates files outside of prefix

[Ryan Schmidt]

On Oct 9, 2009, at 04:04, Scott Haneda wrote:

> These seem to be scoreboard files, which amount to live stats.  I am  
> really new to this territory, and trying to see what I can do to  
> help, so be kind.
>
> grepping the source:
> ftpwho-update.h
>
> # ifdef NON_ROOT_FTP
> #  define SCOREBOARD_PATH CONFDIR "/pure-ftpd-ftpwho"
> # else
> #  define SCOREBOARD_PATH "/var/run/pure-ftpd"
> # endif
> #define SCOREBOARD_PREFIX "client-"
>
> I am assuming # is not a comment in C, or has special treatment.

They're preprocessor directives.

> That path is hard coded, I believe there would need to be a patch  
> made for the portfile to change that to that of ${prefix} in front  
> of it?

Basically yes. I mean you may need to patch these to include @PREFIX@"  
where you want the prefix, and then later reinplace @PREFIX@ with the  
real value of ${prefix}.

> But this may just be the ftpwho command, and where it looks.  I can  
> not find solid reference to where the actual creation of the  
> scoreboard directory happens at.
>
> The man pages, make multiple references to non ${prefix} based  
> locations.  I suppose those need cleaning as well?

Good idea.

> This is a strange one, as you can supply the path to the ftp.log and  
> ftp.xfer.log as startup args, in which case I get to put them  
> wherever I want.  I chose to put them in ${prefix}.
>
> However, each of the defaults is in fact hard coded into the source,  
> and I am guessing needs to be patched.

Probably so.

> Curious, is the correct procedure to have arbitrary paths that  
> people may want to change be a configure option, Or is it unique to  
> Mac Ports, and just reinplace the files carefully?

Hardcoded paths don't seem like a great development decision to have  
made, but it's up to the developers of the software. If that's what  
they decided, then we can just patch it to make those paths match what  
we want in MacPorts.

> I will do my best on this one, but it may be out of my league.  It  
> is currently nomaintainer, so I could take it over, but will need a  
> little handholding I suspect.