[
https://issues.apache.org/jira/browse/GEODE-6824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender closed GEODE-6824.
--------------------------------
> CI Failure: BackupIntegrationTest
> ----------------------------------
>
> Key: GEODE-6824
> URL: https://issues.apache.org/jira/browse/GEODE-6824
> Project: Geode
> Issue Type: Test
> Components: persistence
> Reporter: Jens Deppe
> Assignee: Jens Deppe
> Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> On Windows 2016, this test fails with errors like this:
> {noformat}
> org.apache.geode.internal.cache.backup.BackupIntegrationTest >
> testIncrementalBackupAndRecover FAILED
> java.lang.AssertionError: Restore scripts [] expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.internal.cache.backup.BackupIntegrationTest.restoreBackup(BackupIntegrationTest.java:443)
> at
> org.apache.geode.internal.cache.backup.BackupIntegrationTest.testIncrementalBackupAndRecover(BackupIntegrationTest.java:235)
> {noformat}
> The logs contain more indicators of what's going wrong:
> {noformat}
> [warn 2019/05/31 10:08:47.953 GMT <BackupServiceThread1> tid=0xf5] Unable to
> delete temporary directory created during backup,
> C:\Users\geode\AppData\Local\Temp\backup_15592973278755095066745076642151
> java.io.IOException: Unable to delete file:
> C:\Users\geode\AppData\Local\Temp\junit2122524286779777274\disk_Dir2\backupTemp_1559297327875\BACKUPdiskStore_2.crf
> at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2400)
> at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1721)
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1617)
> at
> org.apache.geode.internal.cache.backup.TemporaryBackupFiles.deleteDirectory(TemporaryBackupFiles.java:133)
> at
> org.apache.geode.internal.cache.backup.TemporaryBackupFiles.cleanupFiles(TemporaryBackupFiles.java:126)
> at
> org.apache.geode.internal.cache.backup.BackupTask.cleanup(BackupTask.java:183)
> at
> org.apache.geode.internal.cache.backup.BackupTask.doBackup(BackupTask.java:125)
> at
> org.apache.geode.internal.cache.backup.BackupTask.backup(BackupTask.java:82)
> at
> org.apache.geode.internal.cache.backup.BackupService.lambda$prepareBackup$0(BackupService.java:62)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Way under the covers, during a backup, we create hard links from the original
> file to a backup file (if hard linking fails then there is a fallback to
> simply copy the file).
> My guess is that the semantics of hard links may have changed between Windows
> versions (which is why we're suddenly seeing this on Windows 2016).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
