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.

[cedon]

+1, using Atom 1.0.19 on Windows 10 Pro x64 and Metalsmith

When I execute node build.js the initial time, and the build directory does not exist, the command will run fine. Any subsequent run will result in:

Error: Failed to write the file at: 'D:\Web\metalsmith\build\articles\test.md'

EPERM: operation not permitted, mkdir 'D:\Web\metalsmith\build\articles'
at Error (native)

Once I close Atom, it works again.

[fredefox]

I think this might be the same issue I'm experiencing on Windows 8 editing files that Visual Studio wants to override. Atom version 1.0.19

[mushishi78]

+1 Windows 7 Atom 1.0.19

[uncleramsay]

+1 Windows 7 Atom 1.2.4

[tcabanski]

Version 1.2.4 on Windows 10 has this locking issue

[fluxdigital]

Version 1.3.2 also have this issue on Windows 8.1.

[Kattixie]

+1 Version 1.3.2 on Windows 7

You should have seen my face when I closed that .tmp folder in the sidebar. I'd spent half an hour trying to delete it, haha. Thanks for this detailed post.

[juanstiza]

+1 on 1.4.3, gulp cannot delete the ./build folder, using del with gulp.

[andreialecu]

I believe this is because of:
nodejs/node-v0.x-archive#8371

Brackets solved a similar issue by creating a native windows node module:
adobe/brackets#6551

[kumarharsh]

I'm facing the same issue, and I'm not even using gulp/grunt. Basically, if I have a folder expanded in tree-view, (even though I've closed the file), and I try to delete the folder by right-click > delete or from command line, I get this error:

Error: EBUSY: resource busy or locked, rmdir 'D:\src\app\shared\components\<MyFolder>'
    at Error (native)

[doivosevic]

+1 1.6.2 on win10
Why is this unaddressed for 2 years?

[kumarharsh]

I think it's a bug with electron, and not atom per se, as Visual Studio Code also runs into the same issues. It's just a theory, so if anyone knows what the dickens is going on, it'd be really good to know.

[andreialecu]

The bug is here: atom/tree-view#718

It can be fixed, just needs a good workaround.

[Convincible]

Have this issue. Confused as to why this is still an issue.

[htownson]

+1 Happening to me. I have been using Atom for years on Ubuntu. Works perfect.

Current job using a Windows computer, probably going to switch to something else.

Atom version: 1.27.1
Windows 10 Pro

[jamestrotter]

This has been open for 4 years. Don't expect anything to change now...

[Convincible]

But why? Is it that hard to fix? Sadly I’m not proficient enough in this area to contribute myself.

[Ajedi32]

AFAIK nobody's really looked into it. I'm not aware of any particular blockers against implementing a fix.

Supposedly it's related to Atom not watching directories recursively on Windows? The most recent news on that is here: atom/node-pathwatcher#115

And it looks like watcher already landed in Atom: https://github.com/atom/atom/blob/v1.27.1/package.json#L18

But considering that doesn't seem to have solved the problem, maybe it's not related to recursive watching of directories? Or maybe Watcher just doesn't implement this properly? Will atom/watcher#104 solve the issue?

[vweevers]

But why? Is it that hard to fix?

Yes. The Windows API for watching files is complicated and very tricky to get right.

AFAIK nobody's really looked into it.

See atom/node-pathwatcher#115 (comment). The new Filesystem Watcher should solve this and other issues, as I understand it. It is available behind a flag since Atom v1.26.0. You can go to Settings / File System Watcher and select "Experimental".

I don't know how stable it is (using it 2 days now) but work is definitely happening.

[arvindDhakad]

See this : #17013 (comment)
It can be fixed.

[Ajedi32]

@arvindDhakad Looks like that issue was fixed in 3dfacaf, which was released in Atom v1.28.0 (5 days ago). I don't know whether or not it's related to this though. Can someone confirm whether or not this issue still occurs in Atom 1.28.0?

[anthonygrignoux]

Can confirm it still occurs. Generally I just need to close the "blocking" folder in the tree view, today I was less lucky and had to close Atom to launch a simple task including a clean command.

I already had a recovery folder, so the comment in #17013 is not really helping.

[kumarharsh]

I don't think the fix for #17013 would fix this issue. They may be related but this issue atleast doesn't delete staged or committed files 😯.

[Convincible]

Can I suggest that this bug is documented somewhere other than literally this issue, as I spent a long time tearing my hair out wondering why my clean command didn't work before I finally found this!

I mean something like a 'Known Bugs on Windows' or 'FYI for Windows Users'.

[michaltajchertdev]

Windows 10, Atom 1.30.0 still doesn't work :(

[AnalogWeapon]

Wow. 4+ years and no fix. I was starting to really like Atom, but now I have to not use it, since restarting Atom every time I build a project isn't feasible. I guess it's hard to fix, yet I use plenty of other IDE's that manage to show the contents of folders and allow other processes to alter them. It's a shame this one thing makes Atom useless.

[Jaid]

This is a very nasty bug indeed. I am also affected by this and it's slowing down my workflow.

My environment:

Part	Specification
Disk	Samsung SSD 850 EVO 500GB
CPU	Intel Core i7-4790K 4x4 GHz
OS	Windows 10 Home Build 17134
Atom	Atom Stable 1.13.1 x64
Package Manager	Scoop Commit ab2ec2e0
Terminal	Hyper 2.1.0
Shell	bash from Git for Windows 2.20.1
Node	NodeJS 11.6.0
npm	pnpm 2.23.1 on npm 6.5.0
Frustration Level	Ask Vegeta!

My Gulp tasks are randomly (about 60% of the times) failing on creating or deleting folders that are visible in tree-view. Changing Settings > Core > File System Watcher didn't help.

Workaround:

My current workaround is enabling Settings > Packages > tree-view > Hide VCS Ignored Files and the problems disappeared then, as long as my external build tools only write to gitignored files, which is true for me and probably most of you too. It comes with its own downsides, but it's good enough for now. Today is not the day VSCode will grab my poor soul on.

Edit: Nevermind! Switched to VSCode and I am pretty happy with it so far. :)

[vweevers]

@ShadowAriaa (and others) unless you have new information, please consider complaining elsewhere. To a friend, family, your dog or even a wall. That would help both you and this thread. I'm watching it for actual updates. Personally I don't care how long it takes. Because I can't help to fix it and Atom is free. I'm not entitled to anything. To Atom and its maintainers: I love you and all the work you do.

[stale]

Thanks for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. Because the Atom team treats their issues as their backlog, stale issues are closed. If you would like this issue to remain open:

1. Verify that you can still reproduce the issue in the latest version of Atom
2. Comment that the issue is still reproducible and include:
   • What version of Atom you reproduced the issue on
   • What OS and version you reproduced the issue on
   • What steps you followed to reproduce the issue

Issues that are labeled as triaged will not be automatically marked as stale.

[loop-evgeny]

Still happening in Atom 1.43.0 x64 on Windows 7 SP1.

For me this commonly happens when switching git branches:

• have a folder open in Atom
• create sub-folder and a file under that in Atom
• git commit
• git checkout a branch that doesn't have that folder - this usually goes OK. Atom prompts to close the deleted file if a tab is still open for it.
• git checkout the first branch (that has the new folder) again. This fails with error: cannot stat 'path/to/the/new/file': Permission denied

[seia-soto]

Also, I think Atom should stop watching subdirectory while the parent directory closed in the file tree at left. +1 to this.