Atom can lock files or folders under some circumstances

[diagramatics]

Instead of vaguely explaining, here are the steps for reproducing the bug:

1. If you have a Yeoman-created project folder i.e. generator-webapp created project, run grunt serve. It'll create a .tmp file, and I'll assume you haven't had one at first.
2. When everything goes well expand the folder .tmp in Atom so you can see the subfolders inside.
3. Stop the grunt process.
4. Run grunt serve again, and it will run grunt-contrib-clean to delete .tmp.

It won't. .tmp will still exist as a "corrupted file" and you can't delete it by the Windows Explorer. Command line will show Warning: Unable to create directory [path to .tmp folder]" (Error code: EPERM). Use --force to continue. when trying to create a new .tmp folder.

Go to Atom and try to delete it, and the Dev Tools will show the same error: Uncaught Error: EPERM, operation not permitted: [path to .tmp folder]. All you need to do is close the folder again on the sidebar to remove the folder. I also tried the same method to Sublime Text, and it doesn't do the same, so I assume there's a clash between grunt-contrib-clean and Atom's way of handling files.

Atom is 0.123.0, and Windows is 8.1. Command line running Grunt is running as Administrator.

[durtal]

Thanks for this explanation, doubt I'd have found a solution to this (very simple) issue without such detail (including all warnings, tasks, etc).

[matz3]

I guess this issue is referring to the same problem which was described here #3287 but with version 0.146.0 I also have problems with files getting locked (grunt-contrib-clean but also e.g. in my git client which isn't able to show me the diff until I close the file in Atom).

[diagramatics]

I haven't tried it with the current version yet though. I'll let you know the results if I have the chance to encounter it again.

[lukeapage]

I am having this problem in 0.186.. Its taken me a while to track it down to atom.. incredibly annoying!!!

[tgoyer]

I get this same issue using gulp-clean to delete temporary build folders for watch/livereload. Once I browse the temporary folder, Atom locks it and it causes subsequent gulp builds to fail during the clean task.

[FilBot3]

I also experience this same issue. Once I close Atom.io then the folder is released and it is deleted.

[andreialecu]

I have this issue on version 1.0.2

[folknor]

I am having this issue on Win7SP1 on a NTFS drive using Atom 1.0.7 even running in --safe editing files residing on a exFAT or NTFS drive. Confirmed not read-only and with full user access to both drives.

If the files are open in another application, that app can not make any changes to the files while Atom is open.

This is the error I get in the StarCraft 2 Editor, specifically; "Unable to move existing archive (Access is denied.)".

[eppsilon]

+1, using Atom 1.0.15 on Windows 8.1.

[dougrday]

+1, using Atom 1.0.19 on Windows 8.1 (using Gulp instead)

[ammachado]

+1, using Atom 1.0.19 on Windows 10.