Core v4.7rc3

[roberts]

Code: [Select]

$ cat aalib.tcz.md5.txt
ec0c53ed730c5f807d2f7b075552e5ec  aalib.tcz
$ tce-load -w aalib
Downloading: aalib.tcz
Connecting to distro.ibiblio.org (152.19.134.43:80)
wget: server returned error: HTTP/1.1 416 Requested Range Not Satisfiable
aalib.tcz: OK
aalib.tcz: OK
$ cat aalib.tcz.md5.txt
ec0c53ed730c5f807d2f7b075552e5ec  aalib.tcz
ec0c53ed730c5f807d2f7b075552e5ec  aalib.tcz
I tried three or four extensions - three were repeats of the above, and the fourth, advcomp, doubled up the dep file 

[this is with busybox wget]

I would like to follow up with a few more questions.
Did this start to happen with 4.7rc series?
Does it not happen with 4.6.2?

I still have not been able to duplicate. Using your specific example of aalib.tcz
and downloading it fives times shows no duplicate.

Code: [Select]

tc@box:~$ which wget
/usr/bin/wget
tc@box:~$ ls -l /usr/bin/wget
lrwxrwxrwx    1 root     root            17 Aug  8  2011 /usr/bin/wget -> ../../bin/busybox
tc@box:~$ tce-load -w aalib.tcz
Downloading: aalib.tcz
Connecting to distro.ibiblio.org (152.19.134.43:21)
aalib.tcz            100% |************************************************************| 40960  --:--:-- ETA
aalib.tcz: OK
tc@box:~$ cat /mnt/sda1/tce/optional/aalib.tcz.md5.txt
ec0c53ed730c5f807d2f7b075552e5ec  aalib.tcz
tc@box:~$ tce-load -w aalib.tcz
Downloading: aalib.tcz
Connecting to distro.ibiblio.org (152.19.134.43:21)
aalib.tcz            100% |************************************************************| 40960  --:--:-- ETA
aalib.tcz: OK
tc@box:~$ cat /mnt/sda1/tce/optional/aalib.tcz.md5.txt
ec0c53ed730c5f807d2f7b075552e5ec  aalib.tcz
tc@box:~$ tce-load -w aalib.tcz
Downloading: aalib.tcz
Connecting to distro.ibiblio.org (152.19.134.43:21)
aalib.tcz            100% |************************************************************| 40960  --:--:-- ETA
aalib.tcz: OK
tc@box:~$ cat /mnt/sda1/tce/optional/aalib.tcz.md5.txt
ec0c53ed730c5f807d2f7b075552e5ec  aalib.tcz
tc@box:~$ tce-load -w aalib.tcz
Downloading: aalib.tcz
Connecting to distro.ibiblio.org (152.19.134.43:21)
aalib.tcz            100% |************************************************************| 40960  --:--:-- ETA
aalib.tcz: OK
tc@box:~$ cat /mnt/sda1/tce/optional/aalib.tcz.md5.txt
ec0c53ed730c5f807d2f7b075552e5ec  aalib.tcz
tc@box:~$ tce-load -w aalib.tcz
Downloading: aalib.tcz
Connecting to distro.ibiblio.org (152.19.134.43:21)
aalib.tcz            100% |************************************************************| 40960  --:--:-- ETA
aalib.tcz: OK
tc@box:~$ cat /mnt/sda1/tce/optional/aalib.tcz.md5.txt
ec0c53ed730c5f807d2f7b075552e5ec  aalib.tcz
There has been no change in busybox.
If you experience this with 4.6.2 then we know it is not related to this rc series.
4.6 has been out and in use so you would think that others would also be experiencing it.

Lastly, if you can duplicate it then immediately tce-fetch.sh aalib.tcz.md5.txt to be sure it is not the actual file being transfered.

[Juanito]

Did this start to happen with 4.7rc series?

Now that I think about it, it was probably present before 4.7rc - without paying attention to the larger than usual md5 file, it would have looked like an extension needed upgrading.

I still have not been able to duplicate. Using your specific example of aalib.tcz
and downloading it fives times shows no duplicate.

I can duplicate the issue with any extension taken at random - as hinted at, this is quote possibly a result of the Internet "filtering" that goes on here.

Lastly, if you can duplicate it then immediately tce-fetch.sh aalib.tcz.md5.txt to be sure it is not the actual file being transfered.

I did this, in every case with tce-fetch.sh the correct md5 file was downloaded.

[coreplayer2]

The filetool app works great, thanks..   I have noticed one small glitch though, for example appending a new item is often added on the same line as the previous last item instead of a new line.  see screenshot




Also re this app and onboot etc, don't you think "Add item & Remove item" is an improved balanced phraseology  over  "Add & Delete"  ??    I think "remove item" defines precisely the desired action, whereas "delete" leaves open too many questions..

[gerald_clark]

Are you also sometimes manually editing onboot.lst?
There may have been a missing newline on the last entry.

[coreplayer2]

Not this time, actually (to my knowledge) I was surprised to see the last two entries.

Whenever manually adding items, I always hit the carriage key at the end.

[gerald_clark]

Sorry, I was thinking of onboot.lst not .filetool.lst.
Blank last lines are now removed from .filetool.lst during the backup.
That used to not be the case, and you would get an error during backup.

I have not been able to reproduce this.

[roberts]

The filetool app works great, thanks..   I have noticed one small glitch though, for example appending a new item is often added on the same line as the previous last item instead of a new line.  see screenshot




Also re this app and onboot etc, don't you think "Add item & Remove item" is an improved balanced phraseology  over  "Add & Delete"  ??    I think "remove item" defines precisely the desired action, whereas "delete" leaves open too many questions..

OK, I am bored trying to reproduce! More details please.

Is there a DOS file that you are trying to add?
Is your .filetool.lst in DOS format?
Is your /opt and therefore .filetool.lst on a DOS or Windows partition?

If none of the above then key stroke sequence that leads to such condition.

[coreplayer2]

Well now..  I can't reproduce this now either.

I had simply used the "add file" feature today,  selected the file .xsession and the result was an entry added to the end of the last line.   

The example is installed on an Ext2 file system (no windows involved).

I can not be certain who or what app added the previous ssh&d_config entries so am assuming an extension (perhaps one of the ssh app's which I had been trying out made these entries, which was many weeks ago.  memory gets a little fuzzy after a week or two) Though i can't exclude myself from adding the entries either, I normally remember to add a carriage return after the last entry.   In which case I'll have to attempt to recreate the issue.
 
This occurs with Onboot.lst also where much of the fault lies in mixing up manual entries and Apps initiated entries.  The two issues I see most frequently are like this, an entry appended to the end of an existing entry, or an entry added after a blank line after the last line. 

Is it possible to add a provision to check if the a new entry will be added to a newline please? 


I just ran a search for "ssh_config" of the info files using APPS  which came up with no results, so I think it's safe to say these previous entries where not made manually..

[coreplayer2]

Blank last lines are now removed from .filetool.lst during the backup.

Awesome thanks 

[coreplayer2]

Thanks for looking into this roberts.  I have not been able to reproduce the entries which leads me to believe that I probably created the last entries and obviously failed to add a carriage return.