On Tue, 18 Nov 2003, BFD wrote: > Jesse Keating wrote: > >On Tuesday 18 November 2003 06:23, BFD wrote: > >>For the file from my Fedora cd: > >> > >>$md5sum yum-2.0.4-2.noarch.rpm > >>dd4249018c1674b73e9ddab08828303f yum-2.0.4-2.noarch.rpm > >>$sum yum-2.0.4-2.noarch.rpm > >>29472 127 > >> > >>For the file I downloaded > >>$md5sum yum-2.0.4-2.noarch.rpm > >>8a82c3f05fca0a615d1765394376f809 yum-2.0.4-2.noarch.rpm > >>$sum yum-2.0.4-2.noarch.rpm > >>47550 127 > > > >Try actually using "file" on the file. A file extension is by no means > >an indication as to what the file actually is. I am now considering that the problem file was a misnamed .hdr file. Here are some random thoughts that got me there. At this point it may be difficult to resolve the corruption. Some of us were able to download this file correctly. This tells me that at the correct file is on the repository and that the bogus files did not persist. Since web browsers have large and strong caching resources it makes sense that multiple downloads will result in the same bits for you. This can be tested by timing the first and second download of a new file. A download of a cached file can be very quick. Since the "file" command reports 'data' and not some flavor of text like "HTML document text" or "ASCII C program text" I do not expect that the download was cut off short at the end. So what is in the bogus file you have? It is useful to look at _copies_ of the good and bad files side by side. "ls -l" and "wc" will give us the character counts. It would be interesting to see if the files are the same size. If the byte counts matched and if an ftp transfer was used I would look to see if there was a binary .vs. ASCII mode transfer problem. Tinkering I found that if an RPM file is ftp transfered in ASCII mode "file" still reports the file as an RPM but "cmp" will find that byte 151 differs on yum-2.0.4-2.noarch.rpm if this was the trouble. Wondering what the bogus file is I might first try: "strings bogus-yum-2.0.4-2.noarch.rpm | less" "strings bogus-yum-2.0.4-2.noarch.rpm | head -40" Since RPM files have a text rich header and other text rich structures this is often informative. "strings" on most files will result in some clue. Next I might look at the bogus file with "od": "od -x -c bogus-yum-2.0.4-2.noarch.rpm | less" "od -x -c bogus-yum-2.0.4-2.noarch.rpm | head -40" Things like byte swap is easy to spot with od. If you had used a squid or another proxy caching server I would check the logs to see if the good and bad download came from the same IP address. Some load balancing tools and tricks will switch from box to box by giving a different IP address at different times to different requests. Knowing which box can be useful if only one of many boxes are involved. I do not know how the Fedora folks update the site or build their HTML but a browser-->view-->source glance at the HTML does not find anything strange/magic/clever. I am slightly curious what OS and hardware download.fedora.redhat.com is running there is a very slim chance of a file system object reuse bug on one end of the wire. The odds are against the server side of things. Most serious 'public' web sites have refresh tricks to detect and sweep up crud deposited by web site hackers or fat fingered admins. These tools might have quietly refreshed the site and fixed the problem. Hmmm... I just looked at an rpm "header" (.hdr) file with "file" and the answer was 'data'. I looked for but did not find a .hdr file for yum-2.0.4-2.noarch so I cannot double check. But up2date and yum (Yellow dog Updater, Modified) take advantage of these headers to be quick. At this point my guess is that you have misnamed .hdr. By chance was an older or experimental version of yum (indirectly?) being used to update yum?
