Is Restart a Solution?



I am sure this is a familiar problem, even though I have not found my exact scenario through searches.

Basically, every few hours or so, Atom boycotts one of my files from the remote ftp editor. I click to open, Atom doesn’t care how I click, even if I click REALLY HARD, click to open another file no problem, back to the banned-by-Atom file, it is a no-way-Julius-situation. That file is in one of Al Gore’s boxes, LOCKED.

I am very pleased to report that Atom’s FANTASTIC SPEED at shutting down and restarting make this a tolerable problem. If this were Eclipse or Visual Studio, it would be gouge-out-my-eyes-time.

My primary concern with this issue is I think it must reflect a serious problem that is going to be hard to resolve. I have reason to believe the integrity of Atom’s buffer/cache/memory management has been the subject of extensive consideration, much of it devoted to the exact issue of guaranteeing the integrity of the buffer/cache/memory management. The fact this problem pops up has me thinking making that part of Atom work perfectly might be like building the World Trade Center with cooked spaghetti.

On that note, I gotta tell you. given the speed at which our computers run these days, and the availability of RAM enough to run all code from all the systems I ever worked on all loaded memory,

Sometimes I think browser developers, like those at FireFox/Mozilla, Opera. Safari. you name it those systems have more work put into cache management than makes sense – this is just my suspicion unencumbered by knowledge. When browsers were really new, like in 1995, that was when normal people first learned about cache. Most of what was learned was not the benefit or goal, but rather how to clear it to solve problems it caused. The benefit we were getting was we could save bandwidth. That is a good thing, even great if you are running in a terrible internet connection. But when you have solid fast connection, like cities where most people live, by the time you factor in all the work it takes to make complicated cache work

Is this related to Atom unable to open a file without restart? Picture below with a specific case.



In order to figure out what the problem is in this case, it may be necessary to find other people who have had the same problem, and also to see if you experience it when using other FTP packages. I haven’t seen this before.


I bet it happens on any OSX installation of Atom running ftp-remote-edit. I just started running the same config of Atom on Windows to see if it produces the same result.


This might be a good question to take to the Atom Slack. If you can find two people with the same OS to test and see if they both get the same results, that would pretty much seal the deal.


I got onto the Atom Slack.

Is the purpose of Atom Slack different from the purpose of


Not really. It’s just more real-time and you’re more likely to get eyeballs for an open-ended question like, “Is anyone here a Mac user who can spare 10 minutes to attempt to replicate a bug?”

When I direct a question to somewhere else, it’s almost always because I don’t have the answer and my gut says that there’s a place where an answer is more likely to appear. I help people with HTML questions all the time, and that’s definitely not what this forum is for, but it’s something I can do.


Can you narrow down the problem to when it happens? Do you think the connection has died? Most FTP clients I know emit an noop command to prevent the connection from being disconnected. If so, maybe suggest this feature to the author of the package


I missed this comment until now. Remote ftp was one the packages I installed for Atom. I somehow got the impression there were no others to choose from. Your comment prompted me to take another look and I found, of course many to choose from. Hopefully this another package will put an end to the crashes of the access to files. Is there an ftppackage for Atom you are comfortable with?

Thank you again for helping me find my way here.


I am going to do what you said. I am still waiting for my hearing with the Committee regarding regex. I sense a disturbance in the Force emanating from regex and suspect a regex is in league with the Delimiter Problem. Since those cards are now on the table, I might as well mention the Floating Div Scam. That one worries me.

Regex does not have to be so complicated but I accept it even though I am holding on to my spot in the queue to discuss regex with the Committee.

I had read that regex was involved with searching for multi-line strings in Atom, but my brain blocked it out in an attempt to shield me from trauma.

Does this part mean “next line please”?


I use atom-commander primarily for the side-by-side file explorer (it lets me not use FileZilla unless I need to upload a whole bunch of files at once), but it has a bunch of cool features including being able to simply double-click on a file in your remote server to open it in Atom, and then that file automatically uploading on save.

That should be (\r|\n|\r\n).

Regarding the “Floating Div Scam”, I don’t think that it’s a bug. A floating element doesn’t impose its dimensions as a minimum requirement for any of its parents, and there are uses for this. Maybe it was unintended at first, but it’s been a part of CSS since the beginning and people expect it. Now, there is a way to stack a bunch of little boxes horizontally without the blue box losing sight of all of its contents: flexbox. You just have to add the following rule to the blue container:

.container {
  display: flex;
  flex-direction: row;

Here’s a CodePen for reference.


Hopefully switching to a different ftp package be end of the problem. If it goes that way, it will leave remote-ftp implicated as the provider of this behavior.

I see another problem about the same frequency, where a file Atom says a file has been updated on the remote ftp file system but what I see of the file in Atom is different from what I see through ssh or a webrowser viewing the file. Like the file lock problem this problem clears with an Atom restart. These issues together have me restarting Atom up to 5 times a day.

FTP conversation get pretty complicated it is no wonder they foul up at times. I am not sure whether my connections use ftp or ssh.

I just tried Atom Commander and the side by side interface is not helpful to me. The tree view on one side is good. I am going to have to put time into finding a package or getting to the bottom of this problem when I am setup for atom dev.

I tried flex box a few times. They are in league with the floating div scam. I am glad you took a look and I appreciate your perspective even though I think it is an unfortunate perspective. Maybe someday i will learn and see things better.


I think the ftp connection is stable. Only one file will be affected. It think it happens if i am doing things fast. I suspect it is cache problem. but don’t know how to find concrete evidence yet.


Still having the same problem. Every day, once one to three times, Atom chokes on a file or two that will not open. It seems to happen shortly after closing many tabs all at once (30 or more).

I will dig into the connection to see if there is evidence of it shutting down, restarting, etc.

I think the temporary copies of files Atom saves locally are where the problem sits. I think those files can get out of sync. I have the impression Atom does things asynchronously, and speculate that maybe the problem is caused if the are an async queue that runs in conflict with something I am doing. That said, if I had to bet, I bet your first suspicion about the connection is the culprit.

The connection is from my osx (mac) to virtual servers running as guests with VMware on the same machine as my osx workstation. Hummmmmmmmmm… maybe vmware has a flake in it. I really don’t know.