| Summary: | Some SVG submissions are corrupted (0 bytes) | ||
|---|---|---|---|
| Product: | openclipart.org | Reporter: | Adrian <drakaan> |
| Component: | website | Assignee: | 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
Can you put somewhere one of those 'not working' svg? To acces it, and see why the upload script can proceed it ? 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! 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.
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. 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. 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 #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 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? 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... Awesome guys! I'm so happy that you are helping sort this out. Adrian, thanks for taking a stab at the solution. 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 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;) 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;) 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 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. 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. 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
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 ; ") I cant see where is the problem in the source code. Anybody? 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. 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 *** Bug 6737 has been marked as a duplicate of this bug. *** 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 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 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.
