Losing data on open file?


#1

Hi everyone,

I encountered a very strange problem: I lose data on file open. But only 1-2 times per day, on random files. I am using Atom for 2 months now, and it just happend once per week than when I opened a file, it gets trimmed at a random line. For example if the file had 1500 lines, the data after line 832 was truncated, with no notification, and it was automatically saved. The worst is that I have an remote FTP plugin in Atom, and before I realized that the file was cut in half, I already uploaded it on remote. So I lost both local and remote files.

I use only popular plugins like Project Manager, Less autocompiler, Linter, Remote FTP. More of that, I just installed Atom on another machine of mine, and without those plugins I bumped in the same issue!

I’m a bit surprised and angry, and you can argue that the configuration or some settings or something external stuff is the problem, but this is a big issue, and not acceptable at all…

Best regards.


#2

Your workflow and Atom are not compatible. Frustrating.
I am of the opinion that the remote functions are giving this issue.
Is the remote FTP package a Atom core package?

If I were in your shoes I would have moved to something like vsCode long ago already.
Curious - Why have you not done this yet?
(sarcasm := void;)


#3

No, it’s not a core package indeed. This is the package:

It has 600k downloads, therefore I do not expect a plugin with such a hype to cause a this kind of sever error. Althought we do not know ATM if this package is the problem.

You are right, I will move to another editor, but once again: I would expect from a top tier 21th century IDE to have build-in remote workflow or at least a secure, well-debugged third party plugin that will do the job.

Sorry, but I am a bit disappointed…

Thanks for the comment by the way!


#4

I don’t think this has to do with remote-ftp. I don’t know what would cause that, and a reliable method for reproducing it would have to be discovered before an answer could be found. Your bug isn’t like any of the other data loss stories I’ve heard. Some people lose entire files, but I haven’t seen anyone reporting the loss of 600 or so lines randomly without a crash or anything.


#5

Hello.

No. Please don’t thank me. I am a neutral in this case and have no ill will to Atom. No ill will to you. I have no invested interest here.

As far as I know, Atom does not curate packages. So whatever you load is at your own risk. It is more likely for your case that there is a package at fault. Not the Atom core. This means the target for your rage may not be responsible.

Having said that - there can be other causes too. Causes external to Atom text editor and loaded packages. Your service provider, hardware drivers and some OS issues may also count in as suspects. I regularly see strange issues on hardware levels when TCP communication is involved. Asking you to diagnose these with software such as WireShark is however beyond the scope.

Please use some other software for a while. See if you have issues. AND please work with those as though there will be problems (make copy-backups).

I would highly value it if you do return and give feedback on your experiences. With more pattern information it would become more clear how to pin down these problems.

In advance my thanks.


#6

I am not sure that remote-ftp causes the problem, I’m not saying that, but it is quite a possibility.

The amount of the data loss is variable, and it cuts in the middle of the line. When it happens, I can reproduce it on the same file (I recover the file in TC or Windows explorer, and when i reopen in Atom it cuts exactly the same amount. I can reproduce 2-3 times, but only on that specific file, after then suddenly just works again). The weird thing is that when I open the file it autosaves it with the trimmed data, so in the moment when I’m hit with the issue, I already lost local data.

As I said I have installed Atom at 2 different systems, both running windows 10. At hardware level the two systems are different, so I don’t think there is a hardware problem.

Might be an OS problem, but the two OS on the systems were installed separately, nothing in common, only the windows 10 updates obviously.

We are working in LAN, we have a local server, where we have all the projects, but no other editor manifested this data loss problem. So I don’t think that’s a network or an ISP problem.

The projects are hosted in various servers, and the data loss problem appeared randomly among projects. So I don’t think it’s from the remote or some setting in the remote plugin

I used Dreamweaver for 14 year for full-stack LAMP development with no similar problem. I thought Atom will be a wise change. Maybe I will return to DW while this problem persist.

Thank you the answeres anyway!


#7

Thank you for taking the time to give the feedback.

Allow me four questions please:
(If you feel there is a security risk - please do not answer.)

  1. Which anti-virus / firewall do you have?
    (only a concern if both machines have the same)

  2. Which edition of Windows 10 do you have?
    (professional or another)

  3. Are the firewall settings of Windows 10 been adjusted by your IT department?

  4. Did you have these issues from the start or from a specific point in time?
    (After Atom V1.19 or after Win10 Creator’s update, for example)

Safe journey.


#8

There’s an important element in common between your two machines that isn’t very common overall: the file in question is not stored on your local drive. I would expect that you would never experience this issue with a file stored locally.

So it might be a network problem, but not necessarily one that can be fixed. Consider this: networks drop and misplace data all the time. You only have so much throughput, so when a client requests a file from the network, the client and the server perform a lot of checks back and forth to make sure that the data coming through is correct. If a packet gets lost or held up, that packet is quickly (on the order of milliseconds) resent and the user doesn’t perceive any of it unless there’s some issue that causes a traffic jam in the system. That’s a natural byproduct of sending signals through wires. In fact, none of modern computing would be possible without error correction and redundancy. I know this is kind of old news, but I’m emphasizing it because it’s important to remember how tenuous this whole IT infrastructure is.

Now, Atom doesn’t behave like a lot of other IDEs. First off, it’s written in JavaScript, which makes it substantially slower than native code editors like DreamWeaver (again, in milliseconds, and modern 64-bit processors and RAM are so ludicrously huge compared to computers we had just a couple of decades ago that you don’t really notice unless something goes wrong or you’re used to something like emacs starting instantaneously). Atom also does a lot of busy work behind the scenes, checking repeatedly on saved files to keep updated on changes you make outside of the program and reading the files you have stored in open folders to power some of its bells and whistles. Because this is all in JavaScript, it’s all slower than native code.

Here’s what I think is happening: your network isn’t 100% reliable (perfectly normal) and Atom is reacting poorly when you try to open a file that has to be pushed over the network. Since you can reproduce the issue over a short period of time and then stop being able to, it seems like there might be some network traffic threshold that could be implicated, but the main point is that, when Atom looks in a folder that it thinks is part of your filesystem (the mounted server folder), it doesn’t know when it only has part of the file. I don’t know why the file on your server is changed when that happens; I would expect Atom to half-load the file and then mark it as “unsaved” because it’s now different from what’s on disk, but that part of Atom’s functioning is not something I have the expertise to disentangle.


#9
  1. The machines have different anti-virus systems, the generic windows firewall is common only.

  2. Win 10 Pro 64 bit (Build 17134)

  3. We tried to disable the firewall, but the issue reproduced.

  4. I really don’t know, but we didn’t updated Atom. We migrated to this IDE at the beginning of August, and tthe issure was discovered in the first weeks.


#10

That explanation sound logic, but how can I test it? And if this is the problem, how can I find a solution for it?

Maybe I should monitor the network usage in some way? I’m not really into networking, and we do not have a special department for this.

Do you have any suggestion?