[asterisk-bugs] [Asterisk 0014190]: POST files are not truncated

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14190 
====================================================================== 
Reported By:                timking
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14190
Category:                   Core/HTTP
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.1-beta4 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.1 
SVN Revision (number only!): 167416 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2009-01-07 11:14 CST
Last Modified:              2009-01-12 17:01 CST
====================================================================== 
Summary:                    POST files are not truncated
Description: 
If you use the POST files facility in 1.6.0.3-rc1 (in pbx/http.c), or
1.6.1-beta4 or the latest revision (in res/res_http_post.c) then the file
to be written is opened O_CREAT | O_WRONLY.

Surely this is wrong - don't you mean O_CREAT | O_WRONLY | O_TRUNC ? As it
is, replacing a long file with a shorter one ends up with the previous
contents on the end.
====================================================================== 

---------------------------------------------------------------------- 
 (0097545) jamesgolovich (manager) - 2009-01-12 17:01
 http://bugs.digium.com/view.php?id=14190#c97545 
---------------------------------------------------------------------- 
I can confirm this behavior and that it should be changed.  I can throw a
patch together for this but don't believe that should be necessary since it
is such a simple change.

I can't imagine why this would be the intended behavior 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-12 17:01 jamesgolovich  Note Added: 0097545                          
======================================================================