[Walrus] Failed uploads leave garbage on storage and hide following successful transfers

[Gilles Gaillard]

Failing to terminate uploads into a bucket (e.g. by closing the connection) leaves the unterminated transfers in the target bucket and (weird) Walrus responds to GET with information about the second failed upload even when a subsequent upload was successful (I'm using 2.0.2).

In the following example, the files at 13:19 and 13:23 result from failed transfers while the file at 13:26 was correctly uploaded.
Walrus returns wrongly the file at 13:23.

-rw-r--r-- 1 eucalyptus eucalyptus 170559488 2011-03-17 13:19 test-52N4lWg...sAup0T57yl--RErd
-rw-r--r-- 1 eucalyptus eucalyptus 201437184 2011-03-17 13:23 test-523TpZw..
-rw-r--r-- 1 eucalyptus eucalyptus 138788864 2011-03-17 13:26 test-523TpZw...D_I0AdYuN7IQKVIA

>> GET http://10.1.0.3:8773/services/Walrus/gilles-1/?delimiter=%2F&max-keys=1000 HTTP/1.1
<< S3Object [key=test-5, bucket=gilles-1, lastModified=Thu Mar 17 13:23:13 CET 2011, .. }],

[Neil Soman (neilsoman)]

Thanks for the report.

From the file sizes, it seems like the file uploaded at 13:23, was in fact the successful upload and looks like it is the one that should be returned. The rest look like partial uploads and you are right that they are left around and should be cleaned up, but the one that you getting back is the one that succeeded. Am I missing something here?

Do you have a test case?

thanks!
neil

[Gilles Gaillard (gillouxgaillard)]

Seems you are right and I was someway confused: tried to write a proper test case and I am getting the right file attributes and data.
Sorry for the false alert on that side.

Remains the partial upload issue.

[Andy Grimm (agrimm)]

This issue is now being tracked upstream at http://eucalyptus.atlassian.net/browse/EUCA-2760

Please watch that issue for further updates.