NppFTP corrupting files

[messala]

Description of the Issue

Sometimes, when I try to open or save a file directly from and to FTP server, the file become corrupted and turn into a zero bytes file and I lost everything inside it.

Steps to Reproduce the Issue

Unfortunately, I can't realize the steps to reproduce this issue, but it happened several times and in different versions of Npp and NppFTP and both installed and portable editions. I suppose it's related to the concurrent access to the file by the webserver and the NppFTP.

Expected Behavior

Open and save the file properly whithout loss of data.

Actual Behavior

The file become zero bytes and all the content is lost.

Debug Information

Notepad++ v7.5.6 (32-bit) Build time : Mar 19 2018 - 00:26:59 Path : D:\path\Portables\Npp\App\Notepad++\notepad++.exe Admin mode : OFF Local Conf mode : ON OS : Windows 10 (64-bit) Plugins : DSpellCheck.dll mimeTools.dll NppConverter.dll NppExport.dll NppFTP.dll PluginManager.dll

0.27.6 Unicode

FTP

Password

[messala]

I highly recommend to users of Npp-FTP to activate Npp backup. It was my lifeguard.

[chcg]

@messala In case of opening a file from the server it is not clear to me why a zero/corrupted local file is a problem. Just reopening should heal it as the file on the server is still unchanged. So I would consider this more like a small issue. Is this correct? In case of saving is also the file on the server corrupted or just the local one? There a known issues with N++ which could cause N++ to corrupt files e.g. https://github.com/notepad-plus-plus/notepad-plus-plus/issues/4655. So maybe this is already an issue at N++ level.

[messala]

Thanks.

@messala In case of opening a file from the server it is not clear to me why a zero/corrupted local file is a problem. Just reopening should heal it as the file on the server is still unchanged. So I would consider this more like a small issue. Is this correct?

I've never experienced a local file corruption.

In case of saving is also the file on the server corrupted or just the local one?

Yes. And that's the real problem. Especially when we do an save & quit (I stopped doing "save & quit" once I realized this issue).

Actually, I don't really know if it's related to the plugin architecture or to nature of this kind of development environment (on the fly), when it's possible concurrent access between ftp and web server. If it is the case, the NppFTP could upload the file with a temporary name and do the exchange of files server side when all is ok (upload successed and target file being accessible).

There a known issues with N++ which could cause N++ to corrupt files e.g. notepad-plus-plus/notepad-plus-plus#4655. So maybe this is already an issue at N++ level.

I don't use "sleep" state nor "power saving" options.

[messala]

Just adding, this issue is rare. Along an entire project (solo), it happened only twice, for instance.

[Saeedghb]

I have the same issue with several versions of N++ and NppFTP.

When I try to save a file directly on the server, it fails before it's completed.

I get such an error: Upload of C:\Users\SaeedPC\AppData\Roaming\Notepad++\plugins\Config\NppFTP\Cache\[MyUserName]@[MySite].com@ftp.[MySite].com\api\index.php failed

Then a zero size file saves on the server with the desired name.

It's notable that I have not any problem with N++ itselft when opening and saving files. Also my files contains unicode characters (utf-8)

Tested version of N++: 7.7.1 & 7.8 (32 bit) Tested NppFTP version: 0.28.4 unicode & 0.30.1 unicode

However I had the same issue with earlier versions of N++ and NppFTP

[BugZappr]

I'm getting the same stuff on vers. 7.8.5 32-bit on Win7 SP1 32-bit; except there's no server involved I love NPP, but I don't have time to come up with a test case,. It rarely happens., and is hard to catch. Unfortunately, this was a password file; so I won't be using NPP in the foreseeable future, that is, until this is found.

I can tell you that I don't set my computer to suspend or to hibernate; but I do at times, and probably in this case, shut down the computer with NPP open. Sometimes, and possibly in this case, it is with an unsaved file. It always seemed to remember them, and let me save them when I restarted NPP.

I had Autosave installed and set to 10 min.; but oddly enough in this case, I found it not activated. This had happened before, with another file that I thought was important; but I thought it might have been my disk encryption software or a hacker. Now, NPP has been caught doing the same thing, with the same NULs where my password file should be.

Now, to try to find out where my Stimulus check is having just lost all the login info to the Intuit site the IRS uses. Fun stuff. I'm going back to Netbeans, for the time being.

Essentially, I take this to mean that this issue, Notepad++ is corrupting files and opening them with null values. #4655, which is now closed, was in fact, never successfully resolved.

[chcg]

There was a fix integrated for an issue with the N++ backup mechanism which fixed that ticket. There was a not accepted PR about corruption in case of a disk full scenario. Compared to some years back the amount of data corruption issues is quite seldom. Anyhow if you have a valuable file you should have a backup on a separate device as not just SW could corrupt data, but also a HW defect.

[BugZappr]

The above issue was closed in 2018. I had done a fresh install 4/29/19. It turned out the autosave plugin wasn't set so it would actually autosave anything; although I thought I had made the settings to enable it. This happened to me 5/4/20. If the issue was fixed, then either it didn't make it into the plugin repository by 04/29, or there's something else causing it. This did not pertain to a disk that was full, although it had only several gig free, and no swapfile. It doesn't matter if "the amount of data corruption issues is quite seldom". Few people are perfect on their backups, and text editors shouldn't be nuking entire files.

THERE IS NO ENHANCEMENT, ISSUE, BUGFIX, OR REFACTORING, THAT IS MORE IMPORTANT THAN FINDING AND FIXING THIS AWFUL BUG (UNLESS IT RESULTS IN AS MUCH DATA LOSS). UNTIL IT IS FIXED, YOU ARE WASTING YOUR TIME MAINTAINING N++.

Sorry to be the bearer of bad news, an editor that doesn't occasionally, NUL out files is an absolute requirement in a text editor. Saying I should back up files is true (and I do, but not as often as I should), but is NO EXCUSE!!! How about this: Start a poll, and ask users if it's OK for a text editor to have a bug that entirely NULs out files, but pretty infrequently.

I wish I had more to contribute as to how to find the problem. I hope that it happening when letting the system close N++ might be a clue. However, I am am of the strong opinion it is existentially severe; if only users knew. How about putting up a big red warning on the download section that says files are only occasionally getting entirely overwritten with NULs. If users really don't care, it won't be an issue. I really like N++, and have been using it for years. Now, it nuked two long and important files in the last several months. I've been an avid computer user since I got my first APPLE II+. I've NEVER had a text editor sporadically just NUL an entire file. True, I had backups, and true, I lost some important data since the last backup. I don't enjoy using the comparatively slow Netbeans. It can't re-wrap a line. However, slow is a whole lot better than nuking my data. It's that important.

[TothSteven]

Same here, just got my whole days work NULL-ed :(

[AgentGarySeven]

This is long, I apologize in advance.

I am using the latest current 64-bit version (8.1.9).

TL,DR: the only solution is to never use NppFTP in Notepad++ without having Settings->Preferences->Backup->Backup on save->Verbose backup enabled, with "Custom Backup Directory" checked and a custom directory provided. Anything short of this, NppFTP can - and will eventually - fail to upload (if your server experiences issues or your internet connection experiences issues in mid-save), leaving you with a 0 bytes file on the server and no local backups to refer to.

Now for the long exposition:

Today, after about three hours of coding, something went wrong with my server, which is a virtual machine. Because it's a simple virtual machine, it's hosted with lots of other machines and sometimes things can go wrong that aren't actually related to your server, but might look like they are. What happened to me is my server started slowing down dramatically and then stopped responding altogether. Sometimes when this happens, your first inclination is you've accidentally created a while loop that has run away with itself or something to that effect - I was working with the mail server (somewhat unfamiliar territory as it changes every few years) trying to get mail/postfix to work from a web page I was making that would send out an email requested by a user.

When I went to Notepad++ it too was frozen, apparently the server problems had begun in mid-save of the file I was working on and because the server was frozen, Notepad++ appeared to be completely unresponsive. I killed Notepad++ knowing my files would come back up on reload, which of course they did. The problem is that your files are now no longer connected via NppFTP and to reconnect them, you have to reload them from the server (in order for "ctrl-s" to work again to save via FTP). This is clunky, but I imagine there's nothing that can be done about it.

I managed to reboot my server from the command line (s l o w l y), which I hoped would kill whatever errant process was going on, but upon reboot, the server was unreachable. After messing around for about 10 minutes trying to get console access from the hosting provider's tools and blah blah blah, the system magically fixed itself on yet another reboot and started acting like nothing ever happened. Using top to monitor my processes and hit all my web files, I eventually figured that it was probably just the virtual host choking out and had nothing to do with what I was doing.

The last file I had worked on, which had the mail code in it I previously mentioned, was coming up blank when I hit it in a web browser - but throwing no errors in the error log. Thinking my last save had just created a bug that was crashing on the client side, I closed the (now disconnected) files and re-attached to my server with NppFTP to pull the file and get back on track. However, when I pulled the file over, it was blank. I immediately knew what had happened and was kicking myself, got that feeling in the pit of my stomach - DAMN. Yes, this has happened to me before, and not just in Notepad++ to be fair, but previously in a similar setup using UltraEdit.

So it appears that NppFTP can begin a "save to FTP" process that can touch the file on the server, making it zero bytes, fail to finish its upload (not its fault) and what you end up with is an empty file and several hours worth of lost work. Ah, but what of the copy that comes up on re-launch and/or the backup files?

Well, if I had had the wherewithal to copy the text from the page I was working on when I re-launched Notepad++ BEFORE I closed the files out and reconnected with NppFTP - then I could have likely pasted that text into the blank file and been A-OK! But this happens infrequently enough (probably been three or four years since I last had it happen to me) that I don't have that thought process burned into my brain. And I shouldn't have to!

I have local simple backups enabled on Notepad++, but boy are there some problems here. I had "Session snapshot and periodic backup" "Remember" and "Enable" are both checked, but this only keeps saves while you are editing for some unfathomable reason - as soon as you save the file you are working on these "snapshots" disappear, which is... I mean, I can't even believe I'm typing this, so I went and looked at it again, but when I'm editing a file, whether local or on NppFTP, you can watch the snapshot file pop in, and as soon as you hit save, whether local file or NppFTP file, the snapshot file disappears. I can't for the life of me imagine what purpose this serves, but there is always Backup on save, right? Well, "Backup on save->Simple backup" was enabled on my Notepad++ - but I had not checked the box for "Custom Backup Directory," thinking instead it would use the backup path that the snapshots above were using (C:\Users\\AppData\Roaming\Notepad++\backup). This is, however, not correct. Only if you select "Custom Backup Directory" and provide a directory do the .bak files actually start showing up. But even this is a problem, because when you do the "Simple" backup, all files with the same name are overwritten into the same file, without regard to whether or not they might be two different files. So if you're editing two separate "index.html" files, you'll only get the very most recent one you worked on, which is better than nothing I guess, but I wasn't even getting that. NppFTP has its own cache of course (at C:\Users\\AppData\Roaming\Notepad++\plugins\config\NppFTP\Cache) - but these files were all overwritten when I re-attached to NppFTP and re-downloaded my files anyway.

So the bottom line is this:

1) No one can trust that NppFTP will reliably save to the server every time and I mean, that's fair, it's not necessarily NppFTP's fault but 2) There are no local backups of files you are working on when you have saved a file, even if you have snapshots and backups enabled, unless you have selected "Custom Backup Directory" and even then, only the most recent of identically named files unless you choose "Verbose." This is also not NppFTP's fault, but it is stupid and NppFTP should do something to try and compensate for it.

I suggest, if it is possible, that you implement some sort of failsafe caching of a file until you get confirmation back from the server, and create a button in your dash upon reconnection to NppFTP that offers the users a chance to revert to that cache for as long as until they do another save on that identical file - which would then re-create the cache. If NppFTP is launched and a cached file exists that did not get a server response, you could pop up a dialog that tells the user that their file might have gotten corrupted and that if it did, they just have to press that button to revert to the last cache.