The down side of switching to Unix, for me, is having to rewrite the parts of the site that use ASP instead of moving forward.

Turned cache settings off as suggested. Noted there is a statement "Please be careful when disable caching. Cached pages will not be re-created and site might start loading slow."

Used FileZilla to delete the previous cached 100 files.

Created a new category 4. Despite the statement above that cached pages will not be re-created the system created 40 cache files!! Examination of the 'last modification' date shows that 22 of these were created currently and and 18 copied in from somewhere else - they had yesterday's date on them. Reloaded the shop front page and the new category was listed.

Created a new category 5. No change to the cached files. Reloaded the shop front page and Category 5 showed up immediately.

This seems to have resolved the problem of making freshly added categories visible but begs questions:

1. What value is there in having the cache at all.
2. If the shop becomes busy, how much does performance reduce with the cache turned off.
3. If the cache is disabled why are any cache files created at all.

I would appreciate answers to those points.

THE PROBLEM IS NOT FULLY SOLVED

With the cache files present I tried again to update the layout and a reload of the shop front page showed no change.
Emptied the cache (again) using FileZilla.
Reloaded the shop front page and this created two fresh cache files.
The changed display layout shows on the admin page but does not show up on the store front when reloaded.

So the problem that started this thread, the failure to make changes to the layout on the shop as initially reported, still remains even with all the cache files deleted.

Are the current layout settings kept in a different cache or file somewhere else and so that the updated layout information is not being read when the shop front is reloaded?

Oops, I should have checked by filetype. They're not all 136 etc filename extensions. But the filename extensions are all numeric and range from 1368871461 to 1369317255.

When I changed System to read/write the process also changed the directories and files below it. The settings in System/Cache (and logs) do not allow me to change them once the higher level has changed. The 'ticks' against the permissions are present but greyed out as they have been inherited from System.

Fourth file of the set.

I decided to explore a bit further - and see if there are any more clues to where the problem lies.

I added a category and a product to see if that part of the system would work. I was able to add them once the first reported issue had been resolved (see topic "Add Product" on the Fresh Installation board) by provision of a proper function instead of a call to unix one that doesn't exist on a windows server.

I then went to the Shop Front Home Page and expected to see the category that is automatically installed appear in the category box together with the category I created. I also expected the product to show up on the page. These expectations are not unreasonable. Neither appeared and the page stubbornly displayed the exact information it did when when first installed: category box no entries, no product on view. The product is, incidentally, flagged as 'featured' and failed to be shown there either.

As an experiment I changed the language setting from English to Spanish. Wow! - the product was displayed and the categories were listed and the product appeared in the featured panel. Change it back to English - and the entries all disappeared again.

This might give you a clue as to where to start looking for the solution to the problem of the system not working and your actions to solve the problem instead of nit-picking.

As for claims of 'no evidence' - read the above again and again. If the failure of the entered categories and products to appear on the shop front isn't clear evidence of a serious dysfunction then what is?

The fact remains that the problem prevents any use of the system.

If the problem is caused by 'third party' items, then you must assume responsibility for putting in calls to 'third party' systems that clearly aren't working.

Your final comment "nevermind" shows a cavalier attitude to potential users.

Are any of the support team really interested in solving this?