Check out what happens with long log file names in APPS/LOGS. I have three flavours of my app with app names "raceQs", "raceQsStart" and "raceQsRacing" So I created log files named raceQs.txt, racsQsStart.txt and raceQsRacing.txt to capture log files. After running for a while, the files fill and get cycled into .BAK, and look what happens to the file names: RACEQS.BAK RACEQS.TXT RACEQS~1.BAK RACEQS~1.TXT RACEQS~2.BAK RACEQS~2.TXT
Upper-cased and truncated to 8.3. Now, I haven't seen that since my M$ DOS days!
It isn't DOS. Is there some reason that the FAT compatible filenames are an issue for you?
I was unable to determine from the file name if RACEQS~1.TXT or RACEQS~2.TXT related to the raceQsStart or raceQsRacing app.
And it's just a bit more than confusing to have created a file raceQs.Racing.txt and find it renamed to RACEQS~1.TXT. Fortunately my experience with DOS helped me to untangle it.
I also believe there is a deeper issue, that I'm working on, that when this condition occurs, the whole logging sub-system fails. I have just completed a 7 hr test of my app (attempting to capture an inconsistent crash) and find the log files have not been written to. Seethis Google Doc
You can change the project name in eclipse (RQStart, RQRace for example), or when you sideload, change the name of the prg to 8.3 if this is an issue.. Or just add something to what's being written to the log to ID which app it is.
Sure, there are plenty of work-arounds, which is fine as long as you know in advance that a work-around is needed!
But I think there's also a deeper problem that I have described in the attachment to post #6. I have a suspicion that this is a side-effect of the 8.3 re-formatting.
When I looked at the attachment in post #6, my first question was "what's in CIQ_LOG.YML?" as it's got the newest time stamp and should have details on the app crash. The timestamps on the txt and bak files, not so much, as the logged data is timestamped.
This post is about the 8.3 re-naming of the log files, not an app crash. The YML file was created on an earlier run and doesn't contain anything relevant to this issue. The timestamp in the YML relates to an earlier crash and it does correlate with the file date, that's fine.
