[
https://issues.apache.org/jira/browse/LOGCXX-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thorsten Schöning resolved LOGCXX-457.
--------------------------------------
Resolution: Fixed
Fix Version/s: 0.11.0
Changed test4, 5 and 6 to delete their generic files before running and changed
test7 to execute 4, 5 and 6 and simulate a non empty directory that way. The
tests now pass using empty and non empty directory and I hope to not have
totally wasted my time... :-( But all other tests worked with and without empty
directory, so I hope my changes have some purpose.
> 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
> Fix For: 0.11.0
>
>
> 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)
