archive
archive copied to clipboard
Resource locked after extracting file to disk in windows
Hi, I got a problem "Process cannot access the file because it is being used by another process" when I was deleting a zip file after extracting it to disk in windows.
await extractFileToDisk('${path}.zip', '${dirPath}');
File('${path}.zip').deleteSync();
But if I use extractArchiveToDisk() and close inputStream, it works.
final inputStream = InputFileStream('${path}.zip');
final archive = ZipDecoder().decodeBuffer(inputStream);
extractArchiveToDisk(archive, '${dirPath}');
inputStream.close();
File('${path}.zip').deleteSync();
It occurs in my case, and I don't test it in a simple case.
For anyone having the similar issue: you should not call .close() twice.
I'm having a similar problem:
final encoder = ZipFileEncoder();
try {
final pathToBackupFile = join(tmpDir, 'handyman-$datePart.db');
final pathToDatabase = await DatabaseHelper().pathToDatabase();
if (!exists(pathToDatabase)) {
print('''
Database file not found at $pathToDatabase. No backup peformed.''');
return BackupResult(
pathToBackup: pathToBackupFile,
pathToSource: '',
success: false);
}
await copyDatabaseTo(pathToBackupFile, src, this);
encoder.create(pathToZip);
await encoder.addFile(File(pathToBackupFile));
await encoder.close();
//after that some of code for making the zip files
return store(
pathToZippedBackup: pathToZip,
pathToDatabase: pathToBackupFile,
version: version);
} catch (e) {
encoder.closeSync();
rethrow;
}
In my case the 'store' method throws a not implemented error on windows, the encoder.closeSync() runs and then I try to delete the directory that contains the zip file and it fails with the same error: Unable to delete the directory .dclitmp\aa1a0a1f-3748-4d7a-b545-7c214bf02a0e. Error: PathAccessException: Deletion failed, path = 'C:\Users\bsutt\AppData\Local\Temp.dclitmp\aa1a0a1f-3748-4d7a-b545-7c214bf02a0e' (OS Error: The process cannot access the file because it is being used by another process. , errno = 32) #0
I've also tried the async version of encoder.close() with an await but that made no difference.
so with some more testing this does appear to be related to a double close.
I do note that this bug does appear to have been fixed in the 4.x branch.
Any word on when 4.x will be released?
Yeah sorry the 4.0 release is taking so long, I should really just push that out. There was a performance regression I wanted to sort out, but haven't had much time to work on the dart stuff recently.