Bug 5619

Summary: Some SVG submissions are corrupted (0 bytes)
Product: openclipart.org Reporter: Adrian <drakaan>
Component: websiteAssignee: default user for a product <clipart>
Status: CLOSED FIXED QA Contact:
Severity: critical    
Priority: highest CC: anton.tw, jeff
Version: unspecified   
Hardware: x86 (IA32)   
OS: Windows (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: This is the file that Adrian originally posted.
SVG testfile
#3 file saved under .43
A test file as uploaded to the server

Description Adrian 2006-01-17 02:26:59 UTC
I've heard it mentioned repeatedly that there was a problem with uploading 
that needed to be fixed, but I don't see that it has been.

When I upload Inkscape-created SVG graphics (see any of the recent "Dell GX-
620" attempts), the upload appears to occur, but the file is corrupted or 
clobbered (it appears as 0 bytes in the incoming file list).

I'm a big fan of Inkscape, and I'd love to contribute to this effort, but it 
seems like that's not possible right now.
Comment 1 khiraly 2006-01-22 09:30:14 UTC
Can you put somewhere one of those 'not working' svg? To acces it, and see why
the  upload script can proceed it ?
Comment 2 Jon Phillips 2006-01-22 11:19:12 UTC
We are looking into this more and need to figure out what your setup is? Please
report back your system, browser and so forth.

Thanks!
Comment 3 Jon Phillips 2006-01-22 13:15:30 UTC
Created attachment 4429 [details]
This is the file that Adrian originally posted.

This file should become 0-byte after uploading possibly. We are trying to
figure out why because this seems to be happening to several different files.
Comment 4 Adrian 2006-01-24 02:03:59 UTC
Just so there are a few less questions, this is my setup on the machine I've 
been using to attempt the uploads:

Inkscape 0.42

Windows XP Pro SP2

IE 6.0.2900.2180.xp_sp2_gdr.050301-1519

I can move the file to an Ubuntu box and reattempt the upload if you'd like.

As I mentioned to Jon, I'd be happy to help try and fix it, if I know where to 
look and how to get there.
Comment 5 khiraly 2006-01-24 02:14:16 UTC
Adrian: Can you try with different browser (not IE), not matter if its under
linux or not. I was able to upload under linux (debian sid) with firefox 1.0.6.

Comment 6 khiraly 2006-01-24 02:32:33 UTC
Ok. It seems, that I have founded the root of the problem.

The problem are user specific;)

Step to reproduce:
1. find a non working svg: http://www.sparksrocketry.com/Motorcycle.svg
   Important: 
    * the .svg file has no metadata!
    * the license is set to default (Propriatary)!
   Finally, this file normally cant be uploaded 
   (because of lack of metadata and license problem)
2. go to: http://www.openclipart.org/cgi-bin/upload_svg.cgi
3. Try to upload. If I fill the fields (author, title, keyword) the script 
   alert, that it cant be accepted because the license issue
   Important: 
    * If I check the little checkbox, that Im the author(name=publicdomain in
the html), the script accept the file! 
    But the file result is 0-byte length.

Just a remark: If I check the chekbox in the beginning, the script accept the
file without any alert (so Im not informed, that I have missed to fill out the
metadatas).

Another remark about the upload_svg.cgi file:
Why is it two upload button? It confuses the end-users and totally unnecessary.
"Send file now" vs. "Send file"


Proposed workaround:
1. alert the user if the metadata is not filled not matter if the checkbox is
checked or not(publicdomain)

2. Do not accept svg-s with incorrect metadata OR provided the same metadata
fileds as inkscape provided to be able fill out right now.

Hope it helps, sadly I cant investigate more time into this problem because of
my exams.

Khiraly
Comment 7 khiraly 2006-01-24 02:38:48 UTC
#3 Jon: The file which you attached has licens problem too.
Its set to CC attribution and not Public Domain.

The easiest fix (after my opinion) is it a big alert at the main page:

,,We can accept .svg only with license set to Public Domain (in the metadata),
trying to upload another license result 0 length file.''

Khiraly
Comment 8 Bryce Harrington 2006-01-24 05:38:02 UTC
Khiraly, thanks, I've added the notice you've suggested.  Hopefully that will
help  people resolve the issues in the short term.  Thanks _so much_ for
narrowing it down the root cause to something testable, I think that will help
people develop a proper long term fix.

Adrian, would you like to have a stab at implementing what Khiraly recommended
in comment #6?  
Comment 9 Adrian 2006-01-24 06:43:39 UTC
So, if I check "Public Domain" on the website submission form, it's ignored?

I think another fix might be to notify the submitter of the disparity and let
them choose to have the license changed to Public Domain.

I'm off to try this again...
Comment 10 Jon Phillips 2006-01-24 15:53:19 UTC
Awesome guys! I'm so happy that you are helping sort this out.

Adrian, thanks for taking a stab at the solution.
Comment 11 khiraly 2006-01-24 21:05:07 UTC
Created attachment 4450 [details]
SVG testfile

There is something strange.
The file, what I have attached has a license CC Attribution (the same license,
as the comment #3).
This file (bed.svg) can upload with the following step:
1. Browse file, and find this bed.svg
2. Check the publicdomain checkbox
   Remark: do not write anything in the author and the title field
The file uploaded successfully (no 0 byte length)
3. Click on the "Send file now"

This file result 0 byte length with the following steps:
1. Browse file, and find bed.svg
2. Check the publicdomain checkbutton
   Remark: also fill the author and the title field!
3. Click on the "Send file now"

The result is 0 byte length!

Now the strange part:
The #3 attached file result always 0-byte length no matter with which method I
upload.

This file: created with inkscape 0.43 under linux (debian sid)
#3 file: created with inkscape 0.42 under windows

I expected, that we have problems with other software (AI, etc) and not
inkscape. But now I have found two inkscape only file.

I have opened #3 file with inkscape 0.43 and saved under another name, and
tried to upload, and it was successful (like this file attached).

Remark: I have uploaded many file (today, yesterday, the day before yesterday),
can I have access to delete it? (it was test uploads (duplicate uploads))

Khiraly
Comment 12 khiraly 2006-01-24 21:09:10 UTC
Created attachment 4451 [details]
#3 file saved under .43

Sorry for spamming this bugreport;)

Here is the #3 file saved under inkscape 0.43 (linux).
I attache the diff here:
lama@khiraly:~/Desktop$ diff gx520-620-mt.svg gx520-620-mt2.svg
16,18c16,18
<    inkscape:version="0.42"
<    sodipodi:docbase="C:\Documents and Settings\adrians\My Documents\My
Pictures"
<    sodipodi:docname="gx520-620-mt.svg">
---
>    inkscape:version="0.43"
>    sodipodi:docbase="/home/lama/Desktop"
>    sodipodi:docname="gx520-620-mt2.svg">
214c214
<      inkscape:cx="772.06470"
---
>      inkscape:cx="772.06471"
221c221
<      inkscape:window-y="-4" />
---
>      inkscape:window-y="24" />
372d371
<
lama@khiraly:~/Desktop$


As you can see, there is not much difference. Any ideas which cause the
problem?
I vote for the white space;)
Comment 13 khiraly 2006-01-24 21:26:06 UTC
I have mad a mistake in the comment #11, I can upload the #3 attached file
(which was saved under 0.42 and windows) with the first method.

Maybe I remember wrong, but now work fine with the first method (where I dont
fill author, title).

The Motorcycle.svg always buggish, because there is no author and title in the
.svg file, so the uploader always must fill this two field, and its not working.

Sorry again for spamming, I try test more and write less;)
Comment 14 khiraly 2006-01-24 22:59:08 UTC
Ok. Further testing, I suppose, that I have found the problem and the resolution
too.

So the bug appear only, if there is a filetoken parameter. So if there was a
problem, and the upload wasnt successfull, the script store temporary the file,
and demand additional info. But its buggish, and not work (after my opinion).

As I see in the source, the programmer have forgotten open the file, and suppose
there is a filedescriptor (TEMP) around already open. But its not true. So when
the programmer read the whole file, it read nothing, so the result file will be
obviously 0 byte length.

My proposed patch:
at line 66 in the upload_svg.cgi, write this:
open(TEMP, "<",$file);

(is it in the getfromtemporarystorage function)

If you are certain, that the file is already open, write this:
close(TEMP); open(TEMP,"<",$file);

I think that's it. I cant try it right now, because I dont have apache (and
openclipart) installed on my notebook.

Hope this helps something.

Khiraly
Comment 15 Bryce Harrington 2006-01-25 05:25:09 UTC
Good find!

Actually, the program does open the file (else it'd always fail), but the way
it's coded it's really easy to miss the open statement.  If you look on line 77
you'll see it - "if not open TEMP, '<', $file;"

However, I've put in the change anyway, just in case you spotted something I
didn't.  Go ahead and try it and report if it works better or not.
Comment 16 Bryce Harrington 2006-01-25 05:31:05 UTC
Rejon, can you help get Khiraly set up with server access?

I'm going to pepper upload_svg.cgi with some debug messages that may help folks
pinpoint what the script is doing when they run their test files through.

Comment 17 Bryce Harrington 2006-01-25 06:34:08 UTC
Created attachment 4458 [details]
A test file as uploaded to the server

This is an example of the raw SVG uploaded to the server.  This is Khiraly's
bus.svg file
Comment 18 khiraly 2006-01-25 07:02:38 UTC
Bryce attached a temporary file which was created, to obtain more info from the
user.

So the problem finally, that this file is broken. As you can see all the <>"' is
broken in the file (replaced with & lt ; & gt ; &quot;)

I cant see where is the problem in the source code. Anybody?
Comment 19 Adrian 2006-01-25 08:52:04 UTC
multiple places, actually.  Everwhere you see "encode_entities($_,'<>&"')",
those three replacements will happen.

For onscreen representation of those characters in XHTML they're necessary
escapes, but they aren't what you want in the source of an XML file like SVG.
Comment 20 Anton Yu 2006-02-01 21:24:31 UTC
I found it happen to me with the same situation.
no matter I use inkscape or sodipodi to upload the svg file , 
and the incoming dir seems no file, only a filename tag.

I feel upset, and dont know what's wrong ??
my svg file can shows normally under gqview and firefox.

if any solution, please inform me, thx.

antontw at GMAIL dot Com
Comment 21 Nicu Buculei 2006-04-25 15:56:43 UTC
*** Bug 6737 has been marked as a duplicate of this bug. ***
Comment 22 Patricia FIDI 2006-07-29 08:44:26 UTC
Hi all,

My last submissions have any problems now since I've read all comments of this
bug report.
In fact, many have found the problem : once we have submit a file at the first
submission form on OCAL website, we shouldn't press any button of the second
form in the second screen.
- don't choose "public domain" in this form or else. Use Metadata of the file in
inkscape and come back on the first form for sending your file.
- don't try to send another file throught the second form on the second screen.
==> Get back on the first submission form of the first screen.

To the website team : could you hide the code of the second form of the second
screen. Maybe next incoming cliparts will be OK. Just for see.

Note : this bug I've reported about twice files generated automatically by the
form submission is OK now for me : https://bugs.freedesktop.org/show_bug.cgi?id=7527
Comment 23 Patricia FIDI 2006-07-29 08:46:14 UTC
Hi all,

My last submissions have any problems now since I've read all comments of this
bug report.
In fact, many have found the problem : once we have submit a file at the first
submission form on OCAL website, we shouldn't press any button of the second
form in the second screen.
- don't choose "public domain" in this form or else. Use Metadata of the file in
inkscape and come back on the first form for sending your file.
- don't try to send another file throught the second form on the second screen.
==> Get back on the first submission form of the first screen.

To the website team : could you hide the code of the second form of the second
screen. Maybe next incoming cliparts will be OK. Just for see.

Note : this bug I've reported about twice files generated automatically by the
form submission is OK now for me : https://bugs.freedesktop.org/show_bug.cgi?id=7527
Comment 24 ryanlerch 2006-09-06 17:26:26 UTC
resolved by the introduction of cchost

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.