In article <1fd5ae6f55.jim(a)abbeypress.net&gt;, Jim Nagel <netsurf(a)abbeypress.co.uk&gt; wrote: That may well not come last on all filing systems, so no-one make that assumption. Jim doesn't specify what FS(s) all his machines are using. I discovered this when devising a system for ensuring the completeness of my back-ups by testing for the presence of a specific (last) file or directory. As an example, SDFS and Fat32fs differ markedly in the order they copy items elsewhere. Implications probably not mission-critical in Jim's particular case, but are in mine! Best wishes, John -- | John Williams | johnrw(a)ukgateway.net Names for Soul Band:- Soul Beneficiary *

On 12 Apr 2016 Richard Porter <ricp(a)minijem.plus.com&gt; wrote: Doesn't everyone? :-) Best wishes, Peter. -- Peter Young (zfc Os) and family Prestbury, Cheltenham, Glos. GL52, England http://pnyoung.orpheusweb.co.uk pnyoung(a)ormail.co.uk

Richard Porter wrote on 12 Apr: When you do a search, however, !Locate so far lacks the ability to exclude specified directories. That's what decided me to move !Cache and !Scrap to the very end of the root directory. !Locate used to spend ages hunting through them. Now I can simply abort the search before it gets to the end. -- Jim Nagel www.archivemag.co.uk

On Tue, Apr 12, 2016 at 02:49:39PM +0100, netsurf(a)avisoft.f9.co.uk wrote: I am beginning to think this feature should never have been enabled for hoplessly legacy operating systems such as RISC OS. I will go over how this feature works once again. This is in response to this message but is, as usual, aimed at all users. To be clear a cache in any computer program trades one resource for another. Generally a web browser will have numerous caches for different uses. In NetSurf we have three main caches: 1. one held in RAM for decoded images This cache trades processor time (used to decode images from compressed source formats like jpegs) for memory (to hold the decoded images). Without this cache scrolling a page would be glacial as every time an image needs to be plotted, even if it is only a single pixel of it, we would need to decode the entire source image 2. a cache for source objects (the stuff downloaded from web servers) held in memory This cache trades memory for network bandwidth used downloading source objects. Without this every time a page navigation happens within a website all the css, images, javascript etc that did not chnage must be downloaded again which would quickly make browsing unusable. 3. a cache of source objects held on disc. This cache trades disc space and bandwidth for memory. Although not immediately obvious the memory is that from the previous cache and indirectly could be seen as network bandwidth used. This is known as a cache hierachy where one cache backs another. The memory cache size setting deals with the first two of these caches and the disc cache settings the third. The average web page is now well over 2 megabytes [1] and is growing rapidly all the time. You would be much better served having no persistant storage (disc) cache enabled at all by setting its size to zero than by a small one like this. As I keep emphasising again and again the cache is a trade of one resource for another in an attempt to reduce the oveall time to perform the action of visiting a web page. If you are not able to make that trade a net profitable transaction you are better off not doing it at all. The RAM, CPU and disc overhead for enabling the cache greatly exceeds your settings which probably require a minimum of a few hundred megabytes and several weeks to make the trade worthwile on RISC OS. In fact I will add a feature request to the tracker to have a minimum viable size for the cache size options. I fear your expectations around sizes of resources are a little out of date. The default cache sizes on PC platforms is 128 megabytes of memory and a gigabyte of disc. Even these are pretty restrained, for example: my desktop has a recently started copy of chrome with a handful of tabs open and thats reporting well over a gigabyte of memory used and several gigabytes of disc. It is not uncommon for standard PCs to have 8 gigabytes of memory and a terrabyte of hard drive space accessed at rates measured in hundreds of megabytes a second. I know RISC OS has no hope of getting anywhere near such resources but it must be understood that the modern web is orientated around systems of this magnitude of capability. [1] http://www.soasta.com/blog/page-bloat-average-web-page-2-mb/ It is possible you had a cache left over from an earlier version of NetSurf where small files were stored in separate files. Cache improvements merge all smaller files into a few large index files and only use the directories for larger files. Regardless the directories are not accounted for as on most OS they are a very low cost resource and are never enumerated. There is a well known "cache" indicator file created which on most systems is used to indicate to other software that the contents of the directory are not at all "valuble" and may be discarded at will and should not be enumerated. you can always delete the entire cache (without netsurf running) at any time without having any impact at all except it will require all source files to be retrieved from the network. as already stated: with those settings any possible long term benefit you might gain is being lost to overhead as RISC OS disc system is generally poor. The cache is pruned only when adding a new entry which causes the overall cache usage to exceed the set level. at that point the least "valuble" objects are discarded untill the size drops below the desired size. This process is subject to 10% hysteresis to avoid excessive thrashing. No account is taken of the overheads like directory size or block sizes in the usage caclulations on the assumption they will be small compared to the cached data and overheads are computationaly expensive to determine for little gain. no no no The help and manual are out of date and refer to long since removed functionality. It might be useful to include a "purge" cache functionality for security reasons and perhaps ensure integrity when the cache size values are changed. again a feature requiest to cover this will be created. -- Regards Vincent http://www.kyllikki.org/

On Wed, Apr 13, 2016 at 12:06:04PM +0100, David Pitt wrote: 1.8MB/sec to an SSD is nothing to write home about. I'd expect at least 20MB/sec from a modern OS on a spinning disc. B.

After an informative thread on how the disc cache is used by Netsurf I wrote: On 13 Apr 2016 in article <55705bbd12netsurf(a)avisoft.f9.co.uk&gt;, Martin Avison <netsurf(a)avisoft.f9.co.uk&gt; wrote: As 14 months have passed, I though I would report back. The current contents of my RISC OS Netsurf v3.6 disc cache is... Total Files 5,204 Size 530,576,177 Expired Files 4,773 Size 404,997,322 before 30 May 17 3xExpired Files 3,337 Size 280,195,992 before 07 Mar 17 6xExpired Files 1,692 Size 151,695,867 before 20 Sep 16 Total Directories 19,648 Size 40,245,248 Empty 899 There are nearly 900 directories with no files in them - but that is quite a small proportion of the 19,000 directories. And I know from the old thread that these could be deleted without causing any problem. It does still strike me as silly that the number of directories is nearly 4 times the number of files held in them. However, I was surprised by the 90% files that were older than the expiry date - indeed 60% were over 3 times the expiry age, and 30% over 6 times. After more investigation, I could see that there are files right back to April 2016 when the cache was initialised. Are age expired cache files *ever* deleted? If so, when, or are they only deleted if the size limit is exceeded? Have any changes since 3.6 affected this? In an earlier post in that thread I had asked... and the reply was ... On 13 Apr in article <20160413104528.GA24798(a)kyllikki.org&gt;, Vincent Sanders <vince(a)netsurf-browser.org&gt; wrote: I can understand how this applies to the maximum size, but it does not seem to cover the age expiry. Can expired files be manually deleted without causing problems? I suspect that various cache index files would cause problems as they would not be updated. Thanks Martin