[ 
https://issues.apache.org/jira/browse/GEODE-6824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854775#comment-16854775
 ] 

ASF subversion and git services commented on GEODE-6824:
--------------------------------------------------------

Commit f38fef51798ccb2e6492e71f57ab44b6a8d65aee in geode's branch 
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f38fef5 ]

GEODE-6824: Copy backup files using file copy on Windows (#3658)

* GEODE-6824: Copy backup files using file copy on Windows

- Typically hard links would be attempted to be used, however on
  Windows, this results in the backed up file not being deleteable.

Authored-by: Jens Deppe <[email protected]>



> 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
>          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
(v7.6.3#76005)

Reply via email to