Corrupt clientraw files

I suddenly got the message ; “Check Your clientraw files are in the location specified in WDL configuration file and are not corrupted”.
The files are where they shall be, however how can I see if they are corrupted?
The WDL have worked perfectly for years an now I am a little lost…

It would certainly help if you supplied the URL to your WD-live page, so we can check this also.
Maybe there has been a change in the configuration xml
Or a change in the site URL so that the files are searched for on the wrong location.

You can check if the files are correct with a clientraw parser, this one is mine, at Clientraw - Script developers info

Wim

Thank you for your answer, I am sorry I didn’t provide more information.
The direct link is www.stuvebakken.no/wddata/index.html, however I don’t understand what you will see other than the error message.
I have tried your parser, but are not sure I understand how it is supposed to work. I keyed in the address to the directory where the clientraw files are, but I am uncertain if anything happened…
I have attached the clientraw files if that can be of any help.


clientraw.txt (739 Bytes)

clientrawdaily.txt (1.93 KB)

clientrawextra.txt (2.94 KB)

clientrawhour.txt (2.57 KB)

Hi,
The parser displays “not a clientraw file /file not available, switched to local file” before displaying Wim’s data.

I checked http://www.stuvebakken.no/wddata/clientraw.txt (and the others) as per the WDL config, and they are all indeed corrupted, containing

eExQQQMKF11NQQ8bO1JeF0oaSE6bLjMTF0uaQP8QWRQj

Is clientrawrealtimeftp.exe uploading the files ok?

Thanks again for all help!
How can I know if clientrawrealtimeftp.exe is uploading correctly? Can I just delete the *raw files, and will they then be regenerated?
In the WD main window menu there is a buildt in WDL display that seemingly works quite all right like WD itself.

The clientraw files you added to your post are OK. Those are probably copied by you from the C:\wdisplay\webfiles folder.

The files which are in your website folder wddata/ are not OK as @Martyn pointed out, they contain a different file type contents.

First: restart your PC and then WD. That makes sure that there is only one realtime ftp upload taken place.
Then You can check the link @martin supplied to check if the uploaded files are OK. http://www.stuvebakken.no/wddata/clientraw.txt
The file on your webserver should start with something like 12345 0.0 0.0 217 1.8 7

If the files content is different there is probably another upload writing other data on top of your clientraw files.

Wim

I would delete those corrupted clientraw* files from the server too, in case they can’t be over-written.

  • ever lasting problem, it seems, thanks all.
    The .txt files I posted were from the WDL/Wddata directory that runs under the stuvebakken web files. (WD directory, with upload files are placed differently.)
    I have deleted all clientraw
    .txt files found on the server (included the upload ones on the WD directory). In addition I have updated WD with a new download.
    The WDL menu option in WD workes seemingly perfect, however my WDL reports exactely the same error although the clientraw files have been regenerated.

These are the locations WDL is looking for the data as defined in http://www.stuvebakken.no/wddata/wdlconfig.xml:

<clientraw>http://www.stuvebakken.no/wddata/clientraw.txt</clientraw>
<clientrawextra>http://www.stuvebakken.no/wddata/clientrawextra.txt</clientrawextra>
<clientrawdaily>http://www.stuvebakken.no/wddata/clientrawdaily.txt</clientrawdaily>

But it seems nobody is uploading a clientraw file to your webserver at the location they should go: http://www.stuvebakken.no/wddata/
Example when you type this link in your browser: http://www.stuvebakken.no/wddata/clientraw.txt
=> this data is returned eExQQQMKF11NQQ8bO1JeF0oaSE6bLjMTF0uaQP8QWRQj

But that no real data at all, it is your modified 404 error page,
it looks as invalid text, but inspecting the network stream this is the real returned information

<html><head><title>Home Page</title></head>
<body>eExQQQMKF11NQQ8bO1JeF0oaSE6bLjMTF0uaQP8QWRQj</body>
</html>

These are the responses as seen by the inspector

Request URL:http://www.stuvebakken.no/wddata/clientraw.txt
Request Method:GET
[color=red]Status Code:404 Not Found[/color]
Remote Address:51.175.67.158:80
Referrer Policy:no-referrer-when-downgrade

QUESTION: When you check with your FTP program the http://www.stuvebakken.no/wddata/ folder on your webserver, are there any clientraw files?

Wim

Attached files are all generated today after deleting old ones.
They are all from stuvebakken/wddata. (OBS: there is one more; clientdrawhour.txttmp)


clientraw.txt (739 Bytes)

clientrawdaily.txt (1.92 KB)

clientrawextra.txt (2.99 KB)

clientraw.txt (739 Bytes)

  1. you can read and copy using FTP the clientraw.txt from the wddata folder on your website http://www.stuvebakken.no

  2. When others try to read the same file using the full URL http://www.stuvebakken.no/wddata/clientraw.txt they get an 404 with a strange errortext

  3. Maybe you or your webhost does not like others reading your .txt files and therefor modified the .htaccess file?

That is the only explanation left.
And WDL is reading the file using a external link http://www.stuvebakken.no/wddata/clientraw.txt
So it can be considered of reading the text file from another place and denied access as we are denied access when using a browser.

You should try the following:

  1. make a copy of your current /wddata/wdlconfig.xml
  2. remove the lines with the links to the clientraw files as they are not needed
<clientraw>http://www.stuvebakken.no/wddata/clientraw.txt</clientraw>
<clientrawextra>
http://www.stuvebakken.no/wddata/clientrawextra.txt
</clientrawextra>
<clientrawdaily>
http://www.stuvebakken.no/wddata/clientrawdaily.txt
</clientrawdaily>

and see what happens then.

Wim

P.S. IMPORTANT
And what do you see when you click this link: http://www.stuvebakken.no/wddata/clientraw.txt ?
Do you get the clientraw text file or the error message as others see?

Good catch Wim :slight_smile: One more possible clue, it only returns that funky page for .txt files, for other extensions it shows the regular IIS 404 page - http://www.stuvebakken.no/wddata/blah.html so there is something else odd about the server setup.

I agree.
Even if I remove/delete the clientraw.txt file I get the same answer from inside (as well as outside) the web server (eExQQQMKF11NQQ8bO1JeF0oaSE6bLjMTF0uaQP8QWRQj).
Also, the server provides the same answer whatever *.txt I request.

Maybe your server is now set up to auto block any .txt files? If it worked before the question has to be “what changed?”

Nothing happened at all. Only changes had been the dayly snow depth update in WD. But that has been done during the season for many years.
For info; I just also reinstalled WDL (just overwrite), however no other result

It is not only you who can make changes.
Also your provider can do that.
Or someone (Microsoft’s automatic update) installed a new version of IIS which maybe has a new “feature”.

You will have to check that also.

Wim

Strange…
The web server is my own in house machine, controlled by me only, running both WD as well as publishing the www.stuvebakken.no (where WDL is located).

Maybe you could test WDL without the URL’s for the files

  1. make a copy of your current /wddata/wdlconfig.xml
  2. remove the lines with the links to the clientraw files as they are not needed
<clientraw>http://www.stuvebakken.no/wddata/clientraw.txt</clientraw>
<clientrawextra>
http://www.stuvebakken.no/wddata/clientrawextra.txt
</clientrawextra>
<clientrawdaily>
http://www.stuvebakken.no/wddata/clientrawdaily.txt
</clientrawdaily>

and see what happens then.
If WDL runs OK you can better post a new question about IIS and this strange 404 message for all (existing and not-existing) .txt files.
That will interest a different group of readers then this “clientraw” question.

Wim

Unfortunately most of the server expertise here is Apache rather than IIS :frowning:

Unfortunately most of the server expertise everywhere is Apache rather than IIS :frowning:

But if the WDL problem is solved here first, then:
one can google for “IIS deny access to certain file-types” and check if one of those solutions is the culprit
and / or one can google for IIS forums and post the question on another forum

But please, always report back if a solution is found.

Wim