--===============0721385007==
Content-Type: multipart/alternative;
boundary="=====================_273301187==.ALT"

--=====================_273301187==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 08:11 AM 11/30/2006, Paul wrote:
>Hello all. I am using Proftpd 1.2.10 on Solaris 9 4/04. When a file is
>uploaded with spaces, the result in "xferlog.log" is an underscore (_).
>But in "access.log", it results in what it should be, a space.
>
>I've tried upgrading to Proftpd 1.3.0 and ncurses 5.5 from 5.4. Still the
>same results. Any suggestions?
>
>This is a big deal, because I have written a perl program to take action
>on completed ftp uploaded files. And it's going to take enough extra code
>to put deliminators in for space exceptions. Arrggghhhh.


As TJ writes elsewhere, this is correct behavior. xferlog format
requires this.

Since you're using Perl you'll understand this. xferlog format
requires that the individual fields of the log entry can be separated
simply using the single space between each field. Thus you can use
something like this to 'parse' out the log values:
my @fields = split ' ', $logline;

But this then requires that any value _within_ the log entry line has
internal spaces replaced with 'something'. The something is a single
underscore for each blank. A filename field value "Program files/A
bad idea.txt" thus becomes "Program_files/A_bad_idea.txt" in the log
entry line.

So... you end up catering for this oddity of xferlog format using
Perl, like I do.

I look at the filepath and see if it has any underscores and if there
is no existing file found using the filepath as is. If these are
true I delve deeper by searching for a file whose name _could_ match
the log entry if _some_ or all underscores were blanks. And yes,
it's ugly. And looking at this six-year-old code I think I see two
(three?) bugs, but it's been working without bad report! (I won't
say without fail...)

Anyway, this code is blended in with the other code that selects
which xferlog entries to act upon. Checks like: is it an upload, did
it finish with completion code of 'c', does the leading directory
path match one of the expected values, and so forth.


--
I'm a pessimist about probabilities; I'm an optimist about possibilities.
Lewis Mumford (1895-1990)

--=====================_273301187==.ALT
Content-Type: text/html; charset="us-ascii"



At 08:11 AM 11/30/2006, Paul wrote:

Hello all.  I am using
Proftpd 1.2.10 on Solaris 9 4/04.  When a file is

uploaded with spaces, the result in "xferlog.log" is an
underscore (_).

But in "access.log", it results in what it should be, a
space.


I've tried upgrading to Proftpd 1.3.0 and ncurses 5.5 from 5.4. 
Still the

same results.  Any suggestions?


This is a big deal, because I have written a perl program to take
action

on completed ftp uploaded files.  And it's going to take enough
extra code

to put deliminators in for space exceptions. 
Arrggghhhh.


As TJ writes elsewhere, this is correct behavior.  xferlog format
requires this.


Since you're using Perl you'll understand this.  xferlog format
requires that the individual fields of the log entry can be separated
simply using the single space between each field.  Thus you can use
something like this to 'parse' out the log values:

    my  @fields   = split ' ',
$logline;


But this then requires that any value _within_ the log entry line has
internal spaces replaced with 'something'.  The something is a
single underscore for each blank.  A filename field value
"Program files/A bad idea.txt" thus becomes
"Program_files/A_bad_idea.txt" in the log entry line. 



So... you end up catering for this oddity of xferlog format using Perl,
like I do. 


I look at the filepath and see if it has any underscores and if there is
no existing file found using the filepath as is.  If these are true
I delve deeper by searching for a file whose name _could_ match the log
entry if _some_ or all underscores were blanks.  And yes, it's
ugly.  And looking at this six-year-old code I think I see two
(three?) bugs, but it's been working without bad report!  (I won't
say without fail...)


Anyway, this code is blended in with the other code that selects which
xferlog entries to act upon.  Checks like: is it an upload, did it
finish with completion code of 'c', does the leading directory path match
one of the expected values, and so forth. 



--

I'm a pessimist about probabilities; I'm an optimist about
possibilities.

    Lewis Mumford  (1895-1990)




--=====================_273301187==.ALT--



--===============0721385007==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?p...rge&CID=DEVDEV
--===============0721385007==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ProFTPD Users List
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html
--===============0721385007==--