FileManager::loadFileData() does not detect error properly

[rbramante]

Description of the Issue

FileManager::loadFileData() will return success if the fread() returns 0 due to failure. fread() does not distinguish between end-of-file and error, and application should be checking feof() or ferror() to detect which condition occurred. NP++ doesn’t seem to do this and assumes eof.

This resulted in a "succesful" open of a blank document when a network file was able to fopen() but the fread() failed. User should have been given an error that NP++ failed to read the file properly.

Steps to Reproduce the Issue

1. Open a file where the fopen() will succeed, but fread() will fail
2. File opens "successfully" but is blank
3. No way for user to know if they truly successfully opened an empty file or if there was an error.
4. I suppose this could manifest itself at any point fread() failed, i.e. could get a "partial" file opened.

Expected Behavior

User is given an error.

Actual Behavior

NP++ did not report an error and just presented a blank document.

Debug Information

Notepad++ v7.3.3 (32-bit)
Build time : Mar 8 2017 - 03:37:37
Path : C:\Program Files (x86)\Notepad++\notepad++.exe
Admin mode : ON
Local Conf mode : OFF
OS : Windows 7 (64-bit)
Plugins : mimeTools.dll NppConverter.dll NppExport.dll NppFTP.dll PluginManager.dll SpellChecker.dll

[CookiePLMonster]

How would one proceed into reproducing this? Any quick, reliable way to come up with a file which can be opened, but not read?

[rbramante]

Hi, It's not easy to replicate for a locally resident file. It's more likely to be hit with a file residing on a network share where you get a network error between a successful open and a failed read. Hard to hit since it's timing dependent. We were able to hit it consistently using a stubbed file system (local file exists as NTFS reparse point). The Initial open is good (reparse driver lazily hydrates on read, not open) then if the reparse handler had an error trying to hydrate (read) the file from remote storage, the read would fail. Notepadd++ only seemed to check "bytesRead" (0) and not the return condition. To the user this resulted in a "successful" load of what appeared to be an empty file when in reality it should have resulted in some sort of "error reading file" condition. ​Not sure how easy this would be ​to reproduce with local files. I think you'd need some sort of interaction in the file system to allow the open but fail the read. Maybe if you ran in a debugger you could open a remote CIFS file, break before read, sever the network connection and then continue. Might have to worry about stuff like the SMB client pre-reading and caching the file on open so the read still succeeds or something like that, but it would be obvious if that was happening. Rich

…

On Sat, Feb 3, 2018 at 9:56 AM, Silent ***@***.***> wrote: How would one proceed into reproducing this? Any quick, reliable way to come up with a file which can be opened, but not read? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3381 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIeUSosCK3HrUAxUUhoPrilkW1xxndqcks5tRHOOgaJpZM4N1t55> .

[donho]

I managed to reproduce it by copying a 1.5 GB of file in my USB drive, opening it in Notepad++ then removing the USB drive immediately.