Rename doesn't remove the original file


Renaming a file in tree view doesn’t remove the original file, this is the standard behaviour or is a bug?

The original file is requestFlexoverview.php, I rename it to requestPanels.php

Atom version: 0.72.0.


I’m having the same problem. It seems like a bug. I’m using version 0.81.0.


The problem appears to only occur if the file is currently open in a tab. If I rename a file by right-clicking in the tree-view when the file is not open, then no duplicate is created. But if I left-click on a file in the tree view and then rename it (either by by pressing m or by right-clicking) then I end up with a duplicate.


:+1: i’m seeing the same thing.


Still happening in 0.96.0. Also, the issue only occurs when the atom/autosave package is enabled.


Justin checking in 5 months later to say that it’s still happening to me on latest Atom. :frowning:


I’m not seeing the described behavior on the latest Atom (tested on both v0.137.0 and the latest master - 0.138.0-ed5c011) whether or not the autosave package is enabled:

Perhaps you can give a more detailed repro case?


I have autosave enabled. On a fresh OS X install with no important settings it works for a few days. Then it stops working. I don’t know what else to say other than to show off GIFs.


I keep my Atom copy running for days at a time and haven’t experienced this on normal files. There are issues like this when I don’t have access to delete the original file … such as on a network drive or restricted directory. I think that would be expected behavior though.


I can consistently reproduce.

OSX: 10.10.2
Atom: 0.187.0

mkdir /tmp/a
date > /tmp/a/one
atom /tmp/a

Open file “one” in a tab, then rename it. core/autosave is enabled.


Anyone want to work with me to track this down? It’s been there more than a year and the workaround is close all open files before renaming anything. My expectation being that Atom is a github project is that it would be state-of-the-art in terms of git integration and handle file renames correctly in both git and non-git directories. This is really a drag and routinely causes me confusion and busywork to clean up.


I suspect it has something to do with the autosave package being enabled. Because the tab doesn’t get closed on rename then when the tab loses focus it gets saved again. So it may just be that on rename the old tab should be closed before the file is renamed and possibly then opened with the new name.

As a matter of fact, this behavior is already being tracked: