[
https://issues.apache.org/jira/browse/LOGCXX-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14950684#comment-14950684
]
Thorsten Schöning commented on LOGCXX-457:
------------------------------------------
It looks like the other failing tests are 3, which is somewhat similar to 6,
and somethign in 5. Patching 3 the same way like 6 didn't resolve that issue,
though. I guess the difference is with where the first log statement goes...
> timebasedrollingtest fails for seconds related filenames
> --------------------------------------------------------
>
> Key: LOGCXX-457
> URL: https://issues.apache.org/jira/browse/LOGCXX-457
> Project: Log4cxx
> Issue Type: Bug
> Components: Tests
> Affects Versions: 0.11.0
> Environment: Windows 8.1 x64, C++-Builder 10 Seattle
> Reporter: Thorsten Schöning
> Assignee: Thorsten Schöning
>
> I'm building 0.11.0 and except timebasedrollingtest all tests pass. Using
> process monitor I can see that in that test some files with timestamps in
> their name with seconds resolution are not available as expected and form
> looking at the code in my opinion this is a bug in the test and can't work at
> all.
> Looking at the history, problems with this test have been reported before in
> LOGCXX-206, where it first was simply disabled and enabled afterwards, but
> without any noticable changes or documentation to the problem. It just seemed
> to work now.
> But lets look at test 6: First, some filenames are build containing a
> timestamp starting with "now" and each new filename is expected to be one
> second in the future. But the important thing is that the names start with
> "now"!
> Afterwards the tests waits always(!) for at least the next second, is than
> writing to some files and checking the existence of the file names created
> before with the expected timestamp names. Process Monitor reveals that the
> first checked filename is always missing.
> But isn't that expected behavior, because the first fielname is created with
> "now" in mind, explicitly not in the future, and one second is waited
> afterwards, so the writes are in the future now? This looks like it can't
> ever work ever and it's always only the first file missing.
> Besides that, there some code reduncany in that file, so I decided to create
> this bug to document my findings, clean the code up a bit and deal with the
> failing test afterwards.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
