Deleting asteroids - file is locked
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 156
- Forks
- 62
- PR merge metrics
- No merged PRs in 30d
Description
When saving in toolbox, it sometimes reports that file somevoxmap.vx2 is locked, but it fact it was the toolbox that locked that file to count materials in it and did not finished that in time.
This is a threading issue, and you would usually encounter it with large asteroids, as they take a lot longer to decompress. The file is locked during this time.
If an asteroid is deleted through the UI, the Model/ViewModel should kill the thread that is currently examining the asteroid file for resources, thus removing the file lock.
http://stackoverflow.com/questions/4732737/how-to-stop-backgroundworker-correctly
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the Model/ViewModel deletion path and the background resource-counting work described in the issue. Read the linked guidance on stopping BackgroundWorker instances, then verify that deleting a large asteroid releases the file lock before saving and no longer reports somevoxmap.vx2 as locked.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- desktop
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100