temp.track fails when the file is locked

[aminya]

temp.track mode fails when the file is locked. It should probably unlock the file before removing.

EBUSY: resource busy or locked, unlink 'C:\Users\VSSADM~1\AppData\Local\Temp\atom-test-data2020615-10032-1reom34.5toc\000003.log'
Error: EBUSY: resource busy or locked, unlink 'C:\Users\VSSADM~1\AppData\Local\Temp\atom-test-data2020615-10032-1reom34.5toc\000003.log'
 at Object.unlinkSync (fs.js:1008:3)
 at rimrafSync (D:\a\1\s\node_modules\temp\node_modules\rimraf\rimraf.js:306:17)
 at D:\a\1\s\node_modules\temp\node_modules\rimraf\rimraf.js:342:5
 at Array.forEach (<anonymous>:null:null)
 at rmkidsSync (D:\a\1\s\node_modules\temp\node_modules\rimraf\rimraf.js:341:26)
 at rmdirSync (D:\a\1\s\node_modules\temp\node_modules\rimraf\rimraf.js:334:7)
 at rimrafSync (D:\a\1\s\node_modules\temp\node_modules\rimraf\rimraf.js:304:9)
 at cleanupDirsSync (D:\a\1\s\node_modules\temp\lib\temp.js:170:5)
 at process.cleanupSync (D:\a\1\s\node_modules\temp\lib\temp.js:222:19)
 at process.emit (events.js:194:13)
 at App.<anonymous> (D:\a\1\s\out\Atom Dev x64\resources\electron.asar\browser\init.js:63:11)
 at App.emit (events.js:194:13)
 at AtomApplication.exit (D:\a\1\s\src\main-process\atom-application.js:194:9)
 at WebContents.<anonymous> (D:\a\1\s\src\main-process\atom-window.js:234:30)
 at WebContents.emit (events.js:194:13)

@aminya looking at this now!

[aminya]

This may be solved by using the maxBusyTries option from rimraf.

It requires switching to the async API.

Sounds good! Doing some maintenance on the package, and built a release, but I will be sure to tackle this this week. I made a plan of action on how to tackle it 👍

@aminya think I have a fix. I tested locally, but if there a repo or a project I can use to recreate the example to verify that this fixes it?

Latest release should resolve this!

[aminya]

Thanks!

[U1F984]

This still seems to be an issue with the latest 0.9.4 release:

Fail to clean temporary files on exit : Error: EBUSY: resource busy or locked, unlink 'C:\Users\User\AppData\Local\Temp\download202219-7532-1ftxtty.nf0rh\00c274ac-d35e-4224-8b55-2852a9d49cda.docx'
 at Object.unlinkSync (fs.js:1210:3)
 at rimrafSync (C:\Users\User\electron\resources\app.asar\node_modules\rimraf\rimraf.js:306:17)
 at C:\Users\User\electron\resources\app.asar\node_modules\rimraf\rimraf.js:342:5
 at Array.forEach (<anonymous>)
 at rmkidsSync (C:\Users\User\electron\resources\app.asar\node_modules\rimraf\rimraf.js:341:26)
 at rmdirSync (C:\Users\User\electron\resources\app.asar\node_modules\rimraf\rimraf.js:334:7)
 at rimrafSync (C:\Users\User\electron\resources\app.asar\node_modules\rimraf\rimraf.js:304:9)
 at cleanupDirsSync (C:\Users\User\electron\resources\app.asar\node_modules\temp\lib\temp.js:180:5)
 at cleanupSync (C:\Users\User\electron\resources\app.asar\node_modules\temp\lib\temp.js:232:19)
 at process.<anonymous> (C:\Users\User\electron\resources\app.asar\node_modules\temp\lib\temp.js:109:13) {
 errno: -4082,
 syscall: 'unlink',
 code: 'EBUSY',
 path: 'C:\\Users\\User\\AppData\\Local\\Temp\\download202219-7532-1ftxtty.nf0rh\\00c274ac-d35e-4224-8b55-2852a9d49cda.docx'
}

[newash]

I wonder how was increasing maxBusyTries from the default 3 to 5 suppose to fix the fact that a file was locked?
What are you expecting to change for the 4th and 5th time?