Bug 188075 - yum cleans cache on unsucessful operation.
yum cleans cache on unsucessful operation.
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-05 15:32 EDT by Rudolf Kastl
Modified: 2014-01-21 17:53 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-19 16:45:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rudolf Kastl 2006-04-05 15:32:22 EDT
Description of problem:
 i am curious about the fact that yum per default now wipes all files after
successful and unsuccessful operation.  wouldnt it make more sense to only wipe
on successful operation? think about the wasted bandwidth and time etc.

Version-Release number of selected component (if applicable):
yum-2.6.0-1

How reproducible:
always unless yum.conf is adjusted to not clean the cache at all

Steps to Reproduce:
1. yum update
2. killall -9 yum while its still downloading but already has downloaded some
packages
3. yum update 

  
Actual results:
watch it redownloading the same files

Expected results:
not having the cache cleaned on unsuccessful operations.

Additional info:
most probably also applies to fc5
Comment 1 Adam Pribyl 2006-04-08 13:32:56 EDT
I AM VERY ANGRY as yum deleted my complete FC5 yum cache as big as 500MB that I
downloaded right now when I canceled its operation because it was not able to
finish due to bug 188370.

This is awfull behaviour. Yum should not delete the cache itself. If users are
not able to clear it themselfs, there has to be a button in Pirut or whereever,
but do not delete anything without user saying YES.
Comment 2 Jeremy Katz 2006-04-10 14:51:45 EDT
I don't see any way how things could be getting cleaned except when you have a
successful transaction run -- the code is basically:
errors = ts.run()
if errors:
   raise
if not keepcache:
   cleanup

Can you try to add some prints into
/usr/lib/python2.4/site-packages/yum/__init__.py:runTransaction() and make sure
it's the code there being run?
Comment 3 Adam Pribyl 2006-04-11 07:23:45 EDT
I can not reproduce the steps described in original report.

I also can not find any reproducable way how to find a point where cache is
deleted on usuccesful operation but can imagine scenario:
You cancel (ctrl+c, kill) yum in the moment, where some subpart of yum returns
success or yum does not check for error state returned byt subpart, then it ends
with success in runTransaction and deletes cache.

Second scenario I know for sure is:
1. yum update (you download lot of update), on transaction test you end up with
some kind of error. Yum keeps the cache.
2. You need at least to update kernel, yum update kernel, and yum wipes complete
cache.
Comment 4 Ola Thoresen 2006-07-13 03:31:37 EDT
I have seen this as well (fedora development, just a few days ago), but I am not
able to reproduce it.

yum update
.. download headers
.. list updates
.. Is this ok [y/N]: N

yum update
.. download headers again
Comment 5 Asko Tontti 2006-07-13 04:15:35 EDT
I have also seen this few times with FC5. It seems to be time related problem.

I think the problem is that if metadata expires in the cache yum will also
remove all the packages in the cache.


Steps to reproduce the problem:

Run "yum update" but when yum asks to confirm transaction wait an hour or more
(same problem happens if you have a very slow download link or slow mirror and
huge number of packages to download).

After the long wait answer N to transaction and run "yum update" again. This
time yum will remove all the packages in the cache.
Comment 6 Asko Tontti 2006-07-13 04:41:04 EDT
(Correction to the steps: you should download the packages and stop the
transaction to reproduce the problem. Transaction question is too early place to
stop the update operation :)

Note You need to log in before you can comment on or make changes to this bug.