[
https://issues.apache.org/jira/browse/LOGCXX-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14951038#comment-14951038
]
Thorsten Schöning commented on LOGCXX-457:
------------------------------------------
With an empty directory, my test7 commented and changes to generate future file
names removed, only one 1 6 tests fail. Without an empty directory 3 fail
again. I guess the one failing with an empty directory is one of the
stopping/restarting tests, because they should behave like with a non empty
directory after stopping/starting.
> 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)
