Starting fresh would be your quickest option.  

Bob


> On Jan 21, 2015, at 9:44 AM, Woodvine, Brett <[email protected]> wrote:
> 
> Well, nonetheless, whatever the issue I tried the further hack as noted by 
> Bob below.  Didn’t change anything.
>  
> I installed 2.6.2, which went mostly well, but ran me out of space again.  As 
> it won’t be a huge loss to lose what we’ve got I was considering just 
> rebuilding the server fresh, but then it occurred to me that maybe just 
> deleting all the other uploads, then clearing out any leftover files from the 
> repository directory (on the assumption those would be from the failed 
> upload) might be the quicker solution.  But, are there other things in the 
> database that would need cleaning up as well?  Does this make sense to try?
>  
> Thanks.
>  
> From: Shi, Yao-Bin (Larry, GBU-HPSW, Cloud and OS) 
> [mailto:[email protected]] 
> Sent: Tuesday, January 06, 2015 9:53 PM
> To: Gobeille, Robert; Woodvine, Brett
> Cc: [email protected]
> Subject: RE: [FOSSology] Deleting a crashed upload
>  
> It is a different issue with (http://www.fossology.org/issues/5763 
> <http://www.fossology.org/issues/5763>) – configuration issue,
> It looks like this issue is because adj2net is not finished,  
> http://www.fossology.org/issues/6165 <http://www.fossology.org/issues/6165> 
> will fix this type of issue( when wgent_agent/ununpack/adj2nest fails).
>  
> -Larry
>  
> From: fossology [mailto:[email protected] 
> <mailto:[email protected]>] On Behalf Of Gobeille, Robert
> Sent: Wednesday, January 07, 2015 3:17 AM
> To: Woodvine, Brett
> Cc: [email protected] <mailto:[email protected]>
> Subject: Re: [FOSSology] Deleting a crashed upload
>  
> FWIW, the issue to clean this mess is http://www.fossology.org/issues/6165 
> <http://www.fossology.org/issues/6165>
> There was an issue (http://www.fossology.org/issues/5763 
> <http://www.fossology.org/issues/5763>) to fix the problem where a failed 
> ununpack would return success.  It was closed as fixed, but apparently it is 
> not fixed.
>  
> I suspect that even though the ununpack_ars table entry was set to success, 
> that if you look at the job scheduler it will show the ununpack failed.  
> Because the job failed, adj2nest was never run (this creates a tree 
> representation of the upload files).  And because that didn’t run, the upload 
> record upload_mode field was never updated to show that the upload was 
> successful.  This is why you can’t see the upload when you browse in the UI.
>  
> If you want to continue this hack, find that ununpack_ars record and jot down 
> the value for the upload_fk field.  Then modify the upload table record where 
> upload_pk = the upload_fk value.  Set the upload_mode to 104 (it’s a bit 
> field and this will set the upload to having succeeded.  And no, I don’t know 
> if there are other gotcha’s.  This is a seat of the pants hack.
>  
> Bob
>  
>  
> On Jan 6, 2015, at 11:59 AM, Woodvine, Brett <[email protected] 
> <mailto:[email protected]>> wrote:
>  
> Interestingly, once I got in there, there are no rows in that table with 
> ars_success=FALSE.  There is one row with the same date as the problem 
> upload, but in the UI there are no uploads showing for that data to delete.
>  
>  
> From: Gobeille, Robert [mailto:[email protected] 
> <mailto:[email protected]>] 
> Sent: Tuesday, January 06, 2015 12:46 PM
> To: Woodvine, Brett
> Cc: Ma, Dong (Vincent, Open Source Program Office); 
> [email protected] <mailto:[email protected]>
> Subject: Re: [FOSSology] Deleting a crashed upload
>  
> Hi Brett,
>  
> Unfortunately, the option you need (-Z remove orphaned files from the 
> repository) hasn’t been added into the Maintenance section yet.  Sorry about 
> that.
>  
> If you want to try and hack this you can go into the ununpack_ars table and 
> find the failed unpack (ars_success = FALSE).  Set it to true and then see if 
> you can Organize > Uploads > Delete uploaded file.
>  
> Bob Gobeille
>  
> On Jan 6, 2015, at 8:56 AM, Woodvine, Brett <[email protected] 
> <mailto:[email protected]>> wrote:
>  
> Thanks Vincent - sorry for delay, been out through the holidays here.  I’ve 
> tried everything under the maintenance agent with no luck.
>  
>  
> From: Ma, Dong (Vincent, Open Source Program Office) [mailto:[email protected] 
> <mailto:[email protected]>] 
> Sent: Tuesday, December 23, 2014 8:21 PM
> To: Woodvine, Brett; '[email protected] 
> <mailto:[email protected]>'
> Subject: RE: Deleting a crashed upload
>  
> There is one function you can try first is under Admin-Maintenance to queue 
> the maintenance agent to clean up error data.
>  
> Thanks,
> Vincent
>  
> From: fossology [mailto:[email protected] 
> <mailto:[email protected]>] On Behalf Of Woodvine, Brett
> Sent: 2014年12月24日 3:24
> To: '[email protected] <mailto:[email protected]>'
> Subject: [FOSSology] Deleting a crashed upload
>  
> Hey folks.  One of my users managed to try uploading something that was 
> taking up so much space he filled my server, thus stopping everything 
> including the upload.  I managed to free enough space to get Fossology 
> running again, but as the upload never finished, I can’t find it to delete 
> it. 
>  
> I started to dig around and delete some files manually, but I’m thinking 
> there has to be a better way to clean up this mess.
> 
> Any suggestions?  Besides just starting over fresh (which I’m tempted to do)!
>  
> Thanks.
>  
>  
> This message is intended to be confidential and may be legally privileged. It 
> is intended solely for the addressee. If you are not the intended recipient, 
> please delete this message from your system and notify us immediately. Any 
> disclosure, copying, distribution or action taken or omitted to be taken by 
> an unintended recipient in reliance on this message is prohibited and may be 
> unlawful.
> 
>  
>  
> This message is intended to be confidential and may be legally privileged. It 
> is intended solely for the addressee. If you are not the intended recipient, 
> please delete this message from your system and notify us immediately. Any 
> disclosure, copying, distribution or action taken or omitted to be taken by 
> an unintended recipient in reliance on this message is prohibited and may be 
> unlawful.
> 

_______________________________________________
fossology mailing list
[email protected]
http://lists.fossology.org/mailman/listinfo/fossology

Reply via email to