Rare problem with "log" file of the current month

[alb_Ronda]

Hi. I would like to expose a problem that has arisen. Due to a breakdown in the weather station, I had to send it for repair and I have been 4 weeks without obtaining data. When I reconnected it to the computer, I got some errors in the extreme values ​​of my series (I don't know why). When I try to correct them in the "Edit> All time records" section and click on "Fetch log data", it only reads the data of the current month, and not all the previous months, so I cannot retrieve the extreme records of other months to be able to correct the errors that have appeared to me. Comment, that since disconnecting the station, until I have reconnected it, it has left a data gap of about 4 weeks (September 22 to October 15).

As a curiosity, the file name "log" of the two affected months appears as "oct.19.log" and "sept.19.log". I don't know why that punctuation mark is due between the name of the month and the number of the year, which does not appear in the other monthly files.

Let's see if someone could help me. Greetings and thank you.

[HansR]

I can't say anything about the editing, but the file naming issue has had a lot of talk on the forum lately and the implications of it have not - I think - been completely understood. However, I did take the liberty to report it as a bug to the Mono-project and we are now waiting for a solution. You could read that thread (and others) about this issue.

It is not completely clear to me what your configuration is, but from your profile, I assume it is MX on a Windows 7 system. The issue is related to a combination of versions of mono and the 'locale' (the Culture/language settings). It is known to occur in SP, IT, NL, AU and maybe others. It is known NOT to occur in en_GB. If you don't use MX / Mono, than that would open a whole other can of problems btw. So could you describe what system you are using?

In the time you did not use the weather station, you probably (???) did change something to your system. My advice would be to undo that change (lower the Mono version to 5.18 or less) and concatenate the erroneous filenames into the correct filenames. After that, wait for the fix before changing anything.

Oh, and the fact that the log filename has changed is the actual cause that you can not reach your old data, so the filename change is not just a curiosity.

[RayProudfoot]

As a curiosity, the file name "log" of the two affected months appears as "oct.19.log" and "sept.19.log". I don't know why that punctuation mark is due between the name of the month and the number of the year, which does not appear in the other monthly files.

Those two log files are incorrectly named. There is no . within the filename. They should be oct19.log and sept19.log. Change them and try again. Check your data folder there are no others similarly named.

[HansR]

@RayProudfoot
Why is it so difficult to understand the problem behind the point in the filename and thus underestimate it? No,Ray, renaming and trying again won't help. It will only confuse the situation. Read the different threads about this issue.

[HansR]

@mcrossley: You may consider creating a workaround in Cumulus itself at the point where the filename is created: check for the point and if so, remove it. As a result, the filename will always be correct. You may also simply construct the filename yourself from the month number in the date.
If you don't have the time I can send you an attempt to solve it.

Confusion in the filenames is a potential killer.

[RayProudfoot]

@RayProudfoot
Why is it so difficult to understand the problem behind the point in the filename and thus underestimate it? No,Ray, renaming and trying again won't help. It will only confuse the situation. Read the different threads about this issue.

Hans, this is the Cumulus1 forum, not MX. I have been running Cumulus1 for over 10 years and all my logs are named correctly. I don't have any problems reading either log files or dayfile.txt. I know what I'm talking about.

[HansR]

But that means the problem with that point in the filename is going deeper than anybody knows, because that would take it outside mono (and it is already outside Cumulus). It's better to find the cause because you may try, but changing the name and trying again won't work: the name is created by the software, so it will create the same name again. If not, it is an unpredictable name giving, then we would really be talking about a problem.

[RayProudfoot]

Hans, the software hasn’t changed in years. Cumulus cannot be responsible for the incorrect naming of the file. Maybe Windows7 is although given how mature that OS is that would be strange. The OP should ensure he has the latest version of Cumulus.

Stop Cumulus. Edit the two file names, start Cumulus and monitor the filenames as they are updated frequently.

[HansR]

My issue at the Mono project has been related by a Microsoft manager to mscorlib. If that library changes (on whatever platform) and the shared code contains the problem, you may have software as old as Methuselah, but if it uses that library it will be affected. So the question can be reduced to: did alb_ronda have an update or otherwise a change to the system?

[RayProudfoot]

Hans,

That link refers to a probelem that occurs under Linux but not in Windows 10. Given alb_ronda is running W7 it seems unlikely to be the reason. I agree that until we hear from him nothing more can be deduced.

[mcrossley]

@mcrossley: You may consider creating a workaround in Cumulus itself at the point where the filename is created: check for the point and if so, remove it. As a result, the filename will always be correct. You may also simply construct the filename yourself from the month number in the date.

Not so simple as a date format may legitimately contain a dot.

As Ray said though, this is the Cumulus 1 forum, it has nothing to do with the Mono issues with CMX under Linux.

The issue here is the short month format in Windows has changed for some reason. So two solutions...

1. Change the Windows short date format to match what it was previously.
2. Keep the new date format and rename the existing 'old' files to match the new format.

[HansR]

I disagree with how the problem is viewed. Mscorlib no doubt has shared code and the problem has now been spotted on Win7, Win10 and Linux (Mono 5.18 and up; and you ignore my remark about mscorlib). Yes a date may legitimately contain a dot, but not the abbreviation of the month, which is used by Cumulus in creating the filename.

And even if that were true, than it does not solve the issue. To have continuity in the data a change in filename cannot be permitted. So if the world does not offer a solution, you will have to try to find a solution where you can. And that means in the code of Cumulus, until the world makes the change.

Those two log files are incorrectly named. There is no . within the filename. They should be oct19.log and sept19.log.

This conclusion by Ray says it all: the filenames must be without a dot.
Act accordingly.

[mcrossley]

I disagree, but without the original poster responding with his Windows date settings then we will never be certain what the cause of this issue is.

All I can say is that every time this has occurred in the past with C1 it has been due to the Windows date format or locale being changed.

Lots of countries use a dot and space as a separator, so short dates may be something like "d. m. yyyy"

Although your issue on mono has been flagged with a mscorlib label, I believe mono does not use a Microsoft Library on linux but their own Corelib functions
https://github.com/mono/corefx/blob/mas ... fo.Unix.cs

As far as I can see lots of issues flagged mscorlib are actually problems in the mono code.

If Windows had started to randomly change date/time formats I'm pretty sure other people would be shouting about it.

This same user had the the same problem with a dot in the filename back in July 2016 - presumably he fixed it then (he never responded on that thread) and the same problem has recurred.


Is what Cumulus uses to store data and name files ideal - far from it, Steve said he would never have designed it like it is if he knew so many people would use it - it was originally designed for his personal use. You would use ISO date formats, and dot decimals etc. But with a large installed base you cannot easily change it now.

Version 4 of CMX - if it ever sees the light of day - will use the Invariant Culture internally and for all data storage, just converting to user locale for display purposes. It would be provided with a conversion utility to perform a one-off conversion of historic data to the any new formats.

[HansR]

I disagree, [...]

OK, agree, we disagree.

Apparently it is a problem, locale related, which has occurred more or less often in the past and the problem seems to be outside Cumulus, but in the control of the user.

Lots of countries use a dot and space as a separator, so short dates may be something like "d. m. yyyy"

Yes, but that is irrelevant.
The short month format ('MMM') - used by Cumulus - never has a point or at least I have never seen one (I haven't seen a spec either).

Although your issue on mono has been flagged with a mscorlib label, I believe mono does not use a Microsoft Library on linux but their own Corelib functions
https://github.com/mono/corefx/blob/mas ... fo.Unix.cs

The information we get out of the MS system, after reporting the bug, is mscorlib. Your believe may be worth something, for me it is the info I get from MS. Besides that, since MS has become partner in Mono, you may assume (yes, assume, not sure) that there will be shared code. If not, software of that size and complexity becomes unmaintainable. But that means that bugs/changes also will appear at strange places.

As far as I can see lots of issues flagged mscorlib are actually problems in the mono code.

If Windows had started to randomly change date/time formats I'm pretty sure other people would be shouting about it.

We are guessing, yes so am I. But randomly changing? And how many programs would use the date as the basis for a filename?

Is what Cumulus uses to store data and name files ideal - far from it, Steve said he would never have designed it like it is if he knew so many people would use it - it was originally designed for his personal use. You would use ISO date formats, and dot decimals etc. But with a large installed base you cannot easily change it now.

Version 4 of CMX - if it ever sees the light of day - will use the Invariant Culture internally and for all data storage, just converting to user locale for display purposes. It would be provided with a conversion utility to perform a one-off conversion of historic data to the any new formats.

I know how Cumulus forms it's name and I truly believe Steve would never do it again like that. But here we are, this is how it works. And OK, forget about C1 because it is not possible to change that code. But CMX is possible. And very easy. So there is a workaround to solve this problem and eliminate the environment and the user.

Cumulus creates the filename like this:

Code: Select all

	var datestring = logfiledate.ToString("MMMyy");
	return Datapath + datestring + "log.txt";

You can use the formatting with the CultureInfo.InvariantCulture there (and leave everything else untouched) and see if it really solves anything (I think it will). Or, because the abbreviation will probably differ in different langages, either search for the point and remove it (best for keeping the current month abbreviations) or you can use the logfiledate.Month as an index to your own array with month names. Easy and problem solved and independent of any failing date/locale system. I don't see the problem.

As it stands now, I - and not only me - can not upgrade the OS/Mono because of loss of data (as this user describes), we have seen many reports on this. You don't even have a planning for version 4. Don't be idealistic, you say yourself if ever, this is workaround which takes less than half an hour, maybe a bit more if there are more places where a filename is formed like this.

Just give it a workaround so we can continue and leave this filenaming issue behind us even if it's not for C1 (In future I will better look which board a message is in).
It can't be that hard and I do not understand why it is not done.

[Mapantz]

Just give it a workaround so we can continue and leave this filenaming issue behind us

Well, considering that this hasn't cropped up before, how is it an issue with Cumulus?

I think you may want to adjust your attitude?! Reading your posts made me cringe - they are rather demanding.