issue installing bugzilla 4.2.1

[Toufique, Imam]

Hi everyone,

I am running into an issue installing bugzilla 4.2.1. My Perl version is 5.14.1. the error is at the last line. Doing some google search on this issue (at the last line of output from checksetup.pl), it appears that a similar issue has been fixed from version 4.0 on; it was an issue relates to version.pm being .092 or higher. My version.pm is 0.95 and I tried with 4.2.1 and 4.3.1; both gives me the same issue.

Any help on this would be appreciated!

Thanks.

---- Output from checksetup.pl---------
The following Perl modules are optional:
Checking for GD (v1.20) ok: found v2.46
Checking for Chart (v2.1) ok: found v2.4.5
Checking for Template-GD (any) ok: found v1.56
Checking for GDTextUtil (any) ok: found v0.86
Checking for GDGraph (any) ok: found v1.44
Checking for MIME-tools (v5.406) ok: found v5.502
Checking for libwww-perl (any) ok: found v6.03
Checking for XML-Twig (any) ok: found v3.39
Checking for PatchReader (v0.9.6) ok: found v0.9.6
Checking for perl-ldap (any) ok: found v0.43
Checking for Authen-SASL (any) ok: found v2.15
Checking for RadiusPerl (any) ok: found v0.20
Checking for SOAP-Lite (v0.712) ok: found v0.714
Checking for JSON-RPC (any) ok: found v1.01
Checking for JSON-XS (v2.0) ok: found v2.32
Use of uninitialized value in open at /usr/intel/pkgs/perl/5.14.1/lib64/module/r1/x86_64-linux/Test/Taint.pm line 334, <DATA> line 522.
Checking for Test-Taint (any) ok: found v1.04
Checking for HTML-Parser (v3.67) ok: found v3.69
Checking for HTML-Scrubber (any) ok: found v0.09
Checking for Encode (v2.21) ok: found v2.44
Checking for Encode-Detect (any) ok: found v1.01
Checking for Email-MIME-Attachment-Stripper (any) ok: found v1.316
Checking for Email-Reply (any) ok: found v1.202
Checking for TheSchwartz (any) ok: found v1.10
Use of uninitialized value $a in substitution (s///) at Bugzilla/Install/Util.pm line 494, <DATA> line 522.
Use of uninitialized value $a in pattern match (m//) at Bugzilla/Install/Util.pm line 497, <DATA> line 522.
Checking for Daemon-Generic (any) found unknown version
Checking for mod_perl (any) ok: found v2.000005
Invalid version format (non-numeric data) at Bugzilla/Install/Requirements.pm line 679.

[saka...@transtechnology.info]

Hi,

I met the same problem, too.

:
Checking for Daemon-Generic (any) ok: found v0.82
Checking for mod_perl (v1.999022) ok: found v2.000004
Invalid version format (non-numeric data) at Bugzilla/Install/Requirements.pm line 676

[saka...@transtechnology.info]

Hi,

I met the same problem, too.

:
Checking for Daemon-Generic (any) ok: found v0.82
Checking for mod_perl (v1.999022) ok: found v2.000004

Invalid version format (non-numeric data) at Bugzilla/Install/Requirements.pm line 676

[mahathi...@gmail.com]

I ran into the same issue after installing the mod_perl and apache::SizeLimit. Any information regarding this issues??????????????

On Monday, May 7, 2012 10:37:01 PM UTC-7, Toufique, Imam wrote:
> Hi everyone,
>
> I am running into an issue installing bugzilla 4.2.1. My Perl version is 5.14.1. the error is at the last line. Doing some google search on this issue (at the last line of output from checksetup.pl), it appears that a similar issue has been fixed from version 4.0 on; it was an issue relates to version.pm being .092 or higher. My version.pm is 0.95 and I tried with 4.2.1 and 4.3.1; both gives me the same issue.
>
> Any help on this would be appreciated!
>
> Thanks.
>
> ---- Output from checksetup.pl---------
> The following Perl modules are optional:
> Checking for GD (v1.20) ok: found v2.46
> Checking for Chart (v2.1) ok: found v2.4.5
> Checking for Template-GD (any) ok: found v1.56
> Checking for GDTextUtil (any) ok: found v0.86
> Checking for GDGraph (any) ok: found v1.44
> Checking for MIME-tools (v5.406) ok: found v5.502
> Checking for libwww-perl (any) ok: found v6.03
> Checking for XML-Twig (any) ok: found v3.39
> Checking for PatchReader (v0.9.6) ok: found v0.9.6
> Checking for perl-ldap (any) ok: found v0.43
> Checking for Authen-SASL (any) ok: found v2.15
> Checking for RadiusPerl (any) ok: found v0.20
> Checking for SOAP-Lite (v0.712) ok: found v0.714
> Checking for JSON-RPC (any) ok: found v1.01
> Checking for JSON-XS (v2.0) ok: found v2.32

> Use of uninitialized value in open at /usr/intel/pkgs/perl/5.14.1/lib64/module/r1/x86_64-linux/Test/Taint.pm line 334, &lt;DATA&gt; line 522.

> Checking for Test-Taint (any) ok: found v1.04
> Checking for HTML-Parser (v3.67) ok: found v3.69
> Checking for HTML-Scrubber (any) ok: found v0.09
> Checking for Encode (v2.21) ok: found v2.44
> Checking for Encode-Detect (any) ok: found v1.01
> Checking for Email-MIME-Attachment-Stripper (any) ok: found v1.316
> Checking for Email-Reply (any) ok: found v1.202
> Checking for TheSchwartz (any) ok: found v1.10

> Use of uninitialized value $a in substitution (s///) at Bugzilla/Install/Util.pm line 494, &lt;DATA&gt; line 522.
> Use of uninitialized value $a in pattern match (m//) at Bugzilla/Install/Util.pm line 497, &lt;DATA&gt; line 522.

[Tim Bingham]

Greetings,

I have a new installation of Bugzilla 4.2.1 with an Oracle 11.1
database running on Solaris 10. I am unable to attach files.

If I choose auto-detect, I get this error:

"You did not specify a file to attach."

If I specify a file format, I get this one:

"The file you are trying to attach is empty, does not exist, or you
don't have permission to read it."

I have tried Firefox and Safari on a Mac, and Firefox and IE on a PC.
I tried a normal Bugzilla user and the Admin account. I've tried with
text files, Word docs, and Excel spreadsheets.

I checked the size limits for attachments. Maxattachmentsize is set
to 1000. Maxlocalattachment is set to 20000. The file I'm trying to
attach is about 4K.

The Bugzilla server has plenty of disk space available. I tried
setting the permissions on /data/attachments to 777 but that didn't
help so I set them back to 770.

Does anyone have any other suggestions, please?

Thank you,
Tim

[Thorsten Schöning]

Guten Tag Tim Bingham,
am Montag, 16. Juli 2012 um 17:20 schrieben Sie:

> Does anyone have any other suggestions, please?

Try with the official demo systems. If those don't work either, the
problem surely is somewhere ein your browsers or more likely something
in your network like a proxy or else.

https://landfill.bugzilla.org/bugzilla-4.2-branch/

Mit freundlichen Grüßen,

Thorsten Schöning

--
Thorsten Schöning E-Mail:Thorsten....@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon.............030-2 1001-310
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow

[Tim Bingham]

> > Does anyone have any other suggestions, please?
>
>Try with the official demo systems. If those don't work either, the
>problem surely is somewhere ein your browsers or more likely something
>in your network like a proxy or else.
>
>https://landfill.bugzilla.org/bugzilla-4.2-branch/

Thank you for the suggestion. I was able to post an attachment to a
bug on that site without any difficulty, so there must be a problem
with my installation.

Are there any error logs in Bugzilla? I've been unable to find
anything so far that will give me a more-detailed error.

Regards,
Tim

>>Does anyone have any other suggestions, please?
>>

>>Thank you,
>>Tim

[Thorsten Schöning]

Guten Tag Tim Bingham,
am Montag, 16. Juli 2012 um 18:19 schrieben Sie:

> Are there any error logs in Bugzilla? I've been unable to find
> anything so far that will give me a more-detailed error.

Only the ones from your web server and browser, maybe the developer
tools of your browser will help you.

[Tim Bingham]

At 11:20 AM -0400 7/16/12, Tim Bingham wrote:
>I have a new installation of Bugzilla 4.2.1 with an Oracle 11.1
>database running on Solaris 10. I am unable to attach files.
>
>If I choose auto-detect, I get this error:
>
>"You did not specify a file to attach."
>
>If I specify a file format, I get this one:
>
>"The file you are trying to attach is empty, does not exist, or you
>don't have permission to read it."
>

I touched the errorlog file in bugzilla and get output like that
below when I try to attach a file. It claims "zero_length_file" when
I'm sure it's not and I've tried different files. One thing that
seems lacking is the directory structure. The "data" field shows only
the filename, not where it is located. So maybe that is a problem?

---------------------------------------------------------------------------
[8588] 07/16/12 13:03:52 global/user-error.html.tmpl zero_length_file
139.127.218...@upstate.edu
[8588] $param(action) = "insert";
[8588] $param(bug_status) = "NEW";
[8588] $param(bugid) = 27;
[8588] $param(comment) = "";
[8588] $param(contenttypeentry) = "";
[8588] $param(contenttypemethod) = "list";
[8588] $param(contenttypeselection) = "text/plain";
[8588] $param(data) = "Epic.txt";
[8588] $param(description) = "Steps used for EpicDB breakout";
[8588] $param(token) = "1ygZLVWG9m";
[8588] $env(BZ_CACHE_CONTROL) = 1;
[8588] $env(CONTENT_LENGTH) = 4196;
[8588] $env(CONTENT_TYPE) = "multipart/form-data;
boundary=---------------------------7845588215305119672110010672";
[8588] $env(DOCUMENT_ROOT) = "/bugzilla/bugzilla-4.2.1";
[8588] $env(GATEWAY_INTERFACE) = "CGI/1.1";
[8588] $env(HTTPS) = "on";
[8588] $env(HTTP_ACCEPT) =
"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8";
[8588] $env(HTTP_ACCEPT_ENCODING) = "gzip, deflate";
[8588] $env(HTTP_ACCEPT_LANGUAGE) = "en-us,en;q=0.5";
[8588] $env(HTTP_CONNECTION) = "keep-alive";
[8588] $env(HTTP_COOKIE) =
"__utmz=223961823.1339509931.84.32.utmcsr=upload.upstate.edu|utmccn=(referral)|utmcmd=referral|utmcct=/~binghamt/;
__utma=223961823.349264634.1306436724.1341500488.1342057194.96;
DEFAULTFORMAT=advanced;
TUI=expert_fields=0&attachment_text_field=0&history_query=0&people_query=1&information_query=1&custom_search_query=1&custom_search_advanced=0;
LASTORDER=priority%2Cbug_severity; VERSION-Epic%20Unix=unspecified;
COLUMNLIST=priority%20product%20component%20assigned_to%20bug_status%20resolution%20short_desc%20changeddate;
VERSION-DNS=unspecified; VERSION-ChartMaxx%20Unix=unspecified;
VERSION-Watson%20Unix=unspecified; Bugzilla_login=1;
Bugzilla_logincookie=UibRomKSF0";
[8588] $env(HTTP_HOST) = "watson.upstate.edu";
[8588] $env(HTTP_REFERER) =
"https://watson.upstate.edu/attachment.cgi?bugid=27&action=enter";
[8588] $env(HTTP_USER_AGENT) = "Mozilla/5.0 (Macintosh; Intel Mac OS
X 10.6; rv:11.0) Gecko/20100101 Firefox/11.0";
[8588] $env(LD_LIBRARY_PATH) =
"/oracle/product/11.1.0/db_1/lib/:/oracle/product/11.1.0/db_1/lib32";
[8588] $env(NLS_LANG) = ".AL32UTF8";
[8588] $env(ORACLE_HOME) = "/oracle/product/11.1.0/db_1/";
[8588] $env(PATH) = "";
[8588] $env(QUERY_STRING) = "";
[8588] $env(REMOTE_ADDR) = "139.127.218.44";
[8588] $env(REMOTE_PORT) = 52895;
[8588] $env(REQUEST_METHOD) = "POST";
[8588] $env(REQUEST_URI) = "/attachment.cgi";
[8588] $env(SCRIPT_FILENAME) = "/bugzilla/bugzilla-4.2.1/attachment.cgi";
[8588] $env(SCRIPT_NAME) = "/attachment.cgi";
[8588] $env(SERVER_ADDR) = "139.127.9.137";
[8588] $env(SERVER_ADMIN) = "sysadmin\@upstate.edu";
[8588] $env(SERVER_NAME) = "watson.upstate.edu";
[8588] $env(SERVER_PORT) = 443;
[8588] $env(SERVER_PROTOCOL) = "HTTP/1.1";
[8588] $env(SERVER_SIGNATURE) = "";
[8588] $env(SERVER_SOFTWARE) = "Apache/2.2.22 (Unix) mod_ssl/2.2.22
OpenSSL/1.0.1c DAV/2";
[8588] $env(SSL_CIPHER) = "DHE-RSA-CAMELLIA256-SHA";
[8588] $env(SSL_CIPHER_ALGKEYSIZE) = 256;
[8588] $env(SSL_CIPHER_EXPORT) = "false";
[8588] $env(SSL_CIPHER_USEKEYSIZE) = 256;
[8588] $env(SSL_CLIENT_VERIFY) = "NONE";
[8588] $env(SSL_COMPRESS_METHOD) = "NULL";
[8588] $env(SSL_PROTOCOL) = "TLSv1";
[8588] $env(SSL_SECURE_RENEG) = "true";
[8588] $env(SSL_SERVER_A_KEY) = "rsaEncryption";
[8588] $env(SSL_SERVER_A_SIG) = "sha1WithRSAEncryption";
[8588] $env(SSL_SERVER_I_DN) = "[edit: ...snipped...]";
[8588] $env(SSL_SERVER_I_DN_C) = "US";
[8588] $env(SSL_SERVER_I_DN_CN) = "[edit: snipped] CA";
[8588] $env(SSL_SERVER_I_DN_Email) = "sysadmin\@upstate.edu";
[8588] $env(SSL_SERVER_I_DN_L) = "Syracuse";
[8588] $env(SSL_SERVER_I_DN_O) = "[edit: snipped]";
[8588] $env(SSL_SERVER_I_DN_OU) = "IMT";
[8588] $env(SSL_SERVER_I_DN_ST) = "New York";
[8588] $env(SSL_SERVER_M_SERIAL) = "01";
[8588] $env(SSL_SERVER_M_VERSION) = 1;
[8588] $env(SSL_SERVER_S_DN) = "[edit: snipped]";
[8588] $env(SSL_SERVER_S_DN_C) = "US";
[8588] $env(SSL_SERVER_S_DN_CN) = "watson.upstate.edu";
[8588] $env(SSL_SERVER_S_DN_Email) = "sysadmin\@upstate.edu";
[8588] $env(SSL_SERVER_S_DN_L) = "Syracuse";
[8588] $env(SSL_SERVER_S_DN_O) = "[edit: snipped]";
[8588] $env(SSL_SERVER_S_DN_OU) = "IMT";
[8588] $env(SSL_SERVER_S_DN_ST) = "New York";
[8588] $env(SSL_SERVER_V_END) = "Jun 26 19:23:49 2037 GMT";
[8588] $env(SSL_SERVER_V_START) = "Jul 2 19:23:49 2012 GMT";
[8588] $env(SSL_TLS_SNI) = "watson.upstate.edu";
[8588] $env(SSL_VERSION_INTERFACE) = "mod_ssl/2.2.22";
[8588] $env(SSL_VERSION_LIBRARY) = "OpenSSL/1.0.1c";
[8588] $env(TZ) = "US/Eastern";
[8588] $env(UNIQUE_ID) = "UARJd4t-CYkAAB-FCScAAAAE";

#

[Thorsten Schöning]

Guten Tag Tim Bingham,
am Montag, 16. Juli 2012 um 19:16 schrieben Sie:

> One thing that
> seems lacking is the directory structure. The "data" field shows only
> the filename, not where it is located. So maybe that is a problem?

Normally not, if I remember correctly the only browser sending a whole
directory structure is/was the IE. Normally browsers only send file
names because the server is not interested in where the file is stored
on the client, this is something the browser has to handle itself.
Bugzilla gets a handle to the file in the browser using the
CGI::upload and it's the browser who has to send the correct data on
reading that handle.

[Tim Bingham]

> > One thing that
>> seems lacking is the directory structure. The "data" field shows only
>> the filename, not where it is located. So maybe that is a problem?
>
>Normally not, if I remember correctly the only browser sending a whole
>directory structure is/was the IE. Normally browsers only send file
>names because the server is not interested in where the file is stored
>on the client, this is something the browser has to handle itself.
>Bugzilla gets a handle to the file in the browser using the
>CGI::upload and it's the browser who has to send the correct data on
>reading that handle.
>

Thanks for looking at my problem. I have tried Firefox, Chrome, IE,
and Safari on a PC and a Mac and they all have the same problem.
Therefore I can't help but suspect that it is my Bugzilla
installation that has the problem. From the errorlog, I can see that
Bugzilla sees the correct filename and content length, so I can't
figure out why it's triggering a zero-length-file error. I will
continue to try to find places to dig.

Regards,
Tim

[Thorsten Schöning]

Guten Tag Tim Bingham,
am Montag, 16. Juli 2012 um 21:13 schrieben Sie:

> Therefore I can't help but suspect that it is my Bugzilla
> installation that has the problem.

Do you have any extensions installed? I searched for the error message
and found it right after a call to a hook which seems to be able to
change parameters for the uploaded file which could result in your
error thrown. Have a look at Bugzilla::Attachment::_check_data, this
method should be called indirectly in attachment.cgi::insert and
should have got a file handle for the data to upload.

# Get the filehandle of the attachment.
my $data_fh = $cgi->upload('data');

my $attachment = Bugzilla::Attachment->create(
{bug => $bug,
creation_ts => $timestamp,
data => scalar $cgi->param('attach_text') || $data_fh,
description => scalar $cgi->param('description'),
filename => $cgi->param('attach_text') ? "file_$bugid.txt" : scalar $cgi->upload('data'),
ispatch => scalar $cgi->param('ispatch'),
isprivate => scalar $cgi->param('isprivate'),
mimetype => $content_type,
});

sub _check_data {
my ($invocant, $params) = @_;

my $data = $params->{data};
$params->{filesize} = ref $data ? -s $data : length($data);

Bugzilla::Hook::process('attachment_process_data', { data => \$data,
attributes => $params });

$params->{filesize} || ThrowUserError('zero_length_file');
# Make sure the attachment does not exceed the maximum permitted size.
my $max_size = max(Bugzilla->params->{'maxlocalattachment'} * 1048576,
Bugzilla->params->{'maxattachmentsize'} * 1024);

if ($params->{filesize} > $max_size) {
my $vars = { filesize => sprintf("%.0f", $params->{filesize}/1024) };
ThrowUserError('file_too_large', $vars);
}
return $data;
}

ref $data should always be true as CGI::upload gives a file handle,
which is an object, which is a blessed reference. You should add some
debug statements and see where filsesize gets zero, I would suspect
you have some kind of hook which messes with you're upload. The rest
is default Bugzilla code which shoudl work, if it doesn't, there may
be a problem with your CGI perl module.

$params->{filesize} = ref $data ? -s $data : length($data);
warn('Bugzilla upload problem 1: '.ref($data));
warn('Bugzilla upload problem 2: '.$params->{filesize});

Bugzilla::Hook::process('attachment_process_data', { data => \$data,
attributes => $params });
warn('Bugzilla upload problem 3: '.$params->{filesize});

$params->{filesize} || ThrowUserError('zero_length_file');

[reg...@gmail.com]

Hi Tim,

Were you able to figure this one out?

I seem to be having the exact same problem with bugzilla 4.2.1, mysql-5.0.67 on redhat es3.

Same thing:
I am unable to attach files. If I choose auto-detect, I get this error: "You did not specify a file to attach." If I specify a file format, I get this one: "The file you are trying to attach is empty, does not exist, or you don't have permission to read it.".

Just like you I had upped Maxattachmentsize and Maxlocalattachment.
For kicks changed permissions to 777. Still no luck.

Thanks,

Mike

[Thorsten Schöning]

Guten Tag reg...@gmail.com,
am Donnerstag, 23. August 2012 um 17:41 schrieben Sie:

> I seem to be having the exact same problem with bugzilla 4.2.1, mysql-5.0.67 on redhat es3.

Which permissions did you change to 777? Which of the other suggested
measures in the thread to look closer in the problem did you already
do besides upping the attachment size?

Mit freundlichen Grüßen,

Thorsten Schöning

--
Thorsten Schöning E-Mail:Thorsten....@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon.............030-2 1001-310
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln

AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

[dazzed]

On Aug 23, 3:56 pm, Thorsten Schöning <tschoen...@am-soft.de> wrote:
> Guten Tag reg...@gmail.com,
> am Donnerstag, 23. August 2012 um 17:41 schrieben Sie:
>
> > I seem to be having the exact same problem with bugzilla 4.2.1, mysql-5.0.67 on redhat es3.
>
> Which permissions did you change to 777? Which of the other suggested
> measures in the thread to look closer in the problem did you already
> do besides upping the attachment size?
>

Hello,

I finally got back to this.

- 777 on the file I was attempting to attach to the bug.
- I was able to attach a file at https://landfill.bugzilla.org/bugzilla-4.2-branch/
(I noticed this is version 4.2.3, I'm running 4.2.1)
- Tried using Konqueror. Konqueror's error was a little difference.
It ONLY said: "You did not specify a file to attach."

I'm not seeing anything in /var/log/httpd/error_log.

Thanks

[dazzed]

On Oct 10, 7:20 am, dazzed <reg...@gmail.com> wrote:
> On Aug 23, 3:56 pm, Thorsten Schöning <tschoen...@am-soft.de> wrote:
>
> > Guten Tag reg...@gmail.com,
> > am Donnerstag, 23. August 2012 um 17:41 schrieben Sie:
>
> > > I seem to be having the exact same problem with bugzilla 4.2.1, mysql-5.0.67 on redhat es3.
>
> > Which permissions did you change to 777? Which of the other suggested
> > measures in the thread to look closer in the problem did you already
> > do besides upping the attachment size?
>
> Hello,
>
> I finally got back to this.
>
> - 777 on the file I was attempting to attach to the bug.

> - I was able to attach a file athttps://landfill.bugzilla.org/bugzilla-4.2-branch/

> (I noticed this is version 4.2.3, I'm running 4.2.1)
> - Tried using Konqueror.  Konqueror's error was a little difference.
> It ONLY said:  "You did not specify a file to attach."
>
> I'm not seeing anything in /var/log/httpd/error_log.
>
> Thanks

Question: (maybe a dumb one) where on the server is the file being
stored? Could that be an issue?

Thanks,

[Thorsten Schöning]

Guten Tag dazzed,
am Mittwoch, 10. Oktober 2012 um 13:27 schrieben Sie:

> Question: (maybe a dumb one) where on the server is the file being
> stored? Could that be an issue?

This depends on your settings, per default files are only stored in
the database, but depending on their size and your settings they may
be saved in the data/attachments folder of Bugzilla installation
directory. Look at Parameters/Attachments maxattachmentsize and
maxlocalattachment.

[dazzed]

On Oct 10, 9:06 am, Thorsten Schöning <tschoen...@am-soft.de> wrote:
> Guten Tag dazzed,
> am Mittwoch, 10. Oktober 2012 um 13:27 schrieben Sie:
>
> > Question: (maybe a dumb one)  where on the server is the file being
> > stored?  Could that be an issue?
>
> This depends on your settings, per default files are only stored in
> the database, but depending on their size and your settings they may
> be saved in the data/attachments folder of Bugzilla installation
> directory. Look at Parameters/Attachments maxattachmentsize and
> maxlocalattachment.
>

Hello,

Setting:
maxattachmentsize 3000 "in kilobytes"
maxlocalattachment 5000 "in megabytes"
allow_attachment_display on
attachment_base http://nms.subcom.com/attachments/ "NOTE:
Initially this was blank. I changed it to /var/www/html/
attachements/ which apache has full access to. Same error"
allow_attachment_deletion off

The test file I'm trying to load is an ascii file 97 bytes in size.


"paste text as attachment" works. It's attaching a file that has not.


thanks

[dazzed]

Also, I've tried attaching a file via firefox and IE running on a
windows machine with the same results...

[Thorsten Schöning]

Guten Tag dazzed,
am Freitag, 12. Oktober 2012 um 13:31 schrieben Sie:

> maxattachmentsize 3000 "in kilobytes"
> maxlocalattachment 5000 "in megabytes"

From my point of view all files larger than 3000 kb would be stored in
the attachment folder, else directly in the database.

> attachment_base http://nms.subcom.com/attachments/ "NOTE:
> Initially this was blank. I changed it to /var/www/html/
> attachements/ which apache has full access to. Same error"

attachment_base must be a url, not a path and the files in this path
are only fetched by the browser.

> The test file I'm trying to load is an ascii file 97 bytes in size.

This file should have been saved in the database and as I have no more
ideas I only will summarize again what can be the problem, but
afterwards you're on your own, sorry.

* space on the file system
* some hooks influencing the upload
* wrong permissions in the data-folder of Bugzilla
* wrong permissions for your webserver on storing the file temporarily
* some other error with your webserver

[dazzed]

On Oct 12, 9:36 am, Thorsten Schöning <tschoen...@am-soft.de> wrote:
> This file should have been saved in the database and as I have no more
> ideas I only will summarize again what can be the problem, but
> afterwards you're on your own, sorry.
>
> * space on the file system
> * some hooks influencing the upload
> * wrong permissions in the data-folder of Bugzilla
> * wrong permissions for your webserver on storing the file temporarily
> * some other error with your webserver
>

Thanks again for the assistance.

From the following thread

https://bugzilla.mozilla.org/show_bug.cgi?id=771100

I tried commenting out a line in ./Bugzilla/CGI.pm in the function
_fix_utf8

sub _fix_utf8 {
my $input = shift;
# The is_utf8 is here in case CGI gets smart about utf8 someday.
# 20121012 - Commented out this line
# utf8::decode($input) if defined $input && !
utf8::is_utf8($input);
return $input;
}

At this point I was able to attach a file to a bug... Ham fisted but
it worked.

I'm running perl 5.16.0. For kicks I'm going to load the latest
stable (5.16.1).

From there see if I can make sense of this.

Thanks

[dazzed]

On Oct 12, 11:36 am, dazzed <reg...@gmail.com> wrote:

> From the following thread
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=771100
>
> I tried commenting out a line in ./Bugzilla/CGI.pm  in the function
> _fix_utf8
>
> sub _fix_utf8 {
>     my $input = shift;
>     # The is_utf8 is here in case CGI gets smart about utf8 someday.
>     # 20121012 - Commented out this line
>     # utf8::decode($input) if defined $input && !
> utf8::is_utf8($input);
>     return $input;
>
> }
>
> At this point I was able to attach a file to a bug...  Ham fisted but
> it worked.
>
> I'm running perl 5.16.0.  For kicks I'm going to load the latest
> stable (5.16.1).
>
> From there see if I can make sense of this.
>
> Thanks

Hello,

FYI - With perl 5.16.1 installed and the function Bugzilla/CGI.pm back
to it's original form, attaching a file to a bug is still a problem.

[carlos....@gmail.com]

> > Invalid version format (non-numeric data) at Bugzilla/Install/Requirements.pm line 679.

If you as me got here after hitting this error installing Bugzilla, this is the way to fix it:
--- /usr/local/lib64/perl5/Apache/SizeLimit/Core.pm.bak 2013-02-19 13:29:34.067649335 -0500
+++ /usr/local/lib64/perl5/Apache/SizeLimit/Core.pm 2013-02-19 13:29:44.908656677 -0500
@@ -49,7 +49,7 @@
$START_TIME
);

-$VERSION = '0.97-rc1';
+$VERSION = '0.97';

$REQUEST_COUNT = 1;

I probably should find where to report a bug to Apache::SizeLimit and submit this patch.

Regards,
Carlos