Deleting content from files also opened in other programs

[JL LMNCHR]

With the latest update (8.1.9.1), when having a log file open (from Glassfish), when trying to delete its content to clean it, I get the message:

Please check whether if this file is opened in another program

Previously, it had always let me delete the content of files even if other programs had it open.

For me that is the desired behavior. Does anyone know how I can get it without having to install an older version?

[PeterJones]

@jl-lmnchr ,

Sorry, it appears none of the regulars have thought of a workaround for you.

The remainder of this post will show my personal biases regarding this issue; you do not have to agree with me, but my advice in this situation cannot be separated from those biases.

The recent update has Notepad++ doing the right thing, and not being able to overwrite a file that has another process actively writing to it. Trying to erase/empty a logfile while the program is writing to that logfile seems like a bad thing (IMO).

Imagine the scenario when Notepad++ polls the file and shows you most recent contents, you start editing, the external process writes new critical data to the log file, but before Notepad++ polls again to see if it’s been changed, you save and Notepad++ blindly lets you do so: in this circumstance, you just lost the critical data without knowing it.

The way to protect you from this is to honor filesystem locks, which is what Notepad++ now does.

I doubt that the developers would willingly revert that intentional change, and if someone were to make such a feature request, I would lobby against it. Honoring file locks held by external processes is the right thing to do.

If you want the B.A.D. implementation where it doesn’t honor external write-locks, I would suggest you roll back to a version that does what you want. I, on the other hand, will quietly continue celebrating the victory of data integrity that this particular fix represents, and will continue to make use of the new codebase going forward.

[gstavi]

Interesting. Tried to find the fix.
The message indicated in the first post comes from this patch.
Is there another related patch?

As far as I understand, the problem is NOT that Notepad++ would not honor locks. It is that in older versions, Notepad++ failed to write and did not notify the user. So @JL-LMNCHR , it is quite possible you thought you were saving the file but you actually didn’t.
Or you wrote it into the snapshot, which is dreadful in its own because it would lead to a conflict between the on-changing log file and the snapshot backup.

AFAIK, Notepad++ (or any app) cannot choose to honor locks or not. The file system would just not allow the write. Not even an administrator can dishonor locks, he just can terminate the process holding them.

[pnedev]

Hello everyone,

This change was due to finally implementing native Win32 file write access.

@PeterJones ,
I totally agree with you that the ‘right’ behavior is to disallow saving the file when it is being used by another program and thus my Win32 file API fix had that implemented (as can be seen in 8.1.9.1).
But from several reports it seems that quite few users were actually relying on the ‘wrong’ behavior (exactly regarding real time log files) and the change broke their use-cases. That’s why (and maybe because there haven’t been any user complaints so far about the concurrent file access (AFAIK)) Don decided to revert that particular functionality update.

So @JL-LMNCHR , the old Notepad++ behavior is restored in version 8.1.9.3.

@gstavi ,
I don’t know exactly how the operating system handles that but the Win32 file API has the notion of ‘file access sharing’ that is regarding read, write and delete access. I guess it is not total file lock (so file handle lock on open) but kind of per access lock mechanism meaning that each read/write operation is atomic (not concurrent but serialized by the system).

[gstavi]

@pnedev
The patch I indicated turns an ‘if’ clause into an if-else (with opposite condition).
As far as I understand the code, if a user was running in admin-mode and tried to save the file and Notepad++ failed to open it:
Old version: silently failed (‘if’ is skipped). User thinks the file is saved but it isn’t.
New version: user gets a failure message (from the new ‘if’) and knows the file was not saved.

So users complain that they see a message they haven’t seen before but the question is whether before they actually successfully saved over the log file or just thought they did. To me it looks like a fix for a real bug. Silent failure for “save” is really bad.

A log file is probably created by its application with read-sharing so other applications can open it for read but will fail if they open it for write.

[pnedev]

@gstavi said in Deleting content from files also opened in other programs:

Silent failure for “save” is really bad.

I totally agree.
But the patch you are talking about is another thing - it affects saving in Admin mode AFAIU.
In GitHub there was an issue report about that log file behavior change:
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/10751#issuecomment-970245443
It was tested by the reporter after the fix and is working like it always did - log is emptied without problems.

[gstavi]

@pnedev
The first post in this topic refers to the new message “Please check whether if this file is opened in another program” which is under

if (_isAdministrator) { ... }

That was added by the patch I indicated. So I guess he is running as Admin.

Regarding the discussion you pointed.

• I think it is right that Notepad++ should open files while agreeing to maximal sharing. This will reduce open failures for files that are open by other apps.
• The concept of truncating a file that is shared by 2 apps for write is fucked up. The other application is unaware of the truncation so depending on how it is written (e.g. with async I/O) it could try to resume writing to the same offset that is now beyond the end of file. Couldn’t figure out from Microsoft docs what is the expected behavior.

But then again, Notepad++ should try to reasonably do what the user requests of it and the user should pay the price for doing dumb things.

[gstavi]

Some info from Microsoft docs:
This is from SetFilePointer. I guess it applies to similar cases as well.

It is not an error to set a file pointer to a position beyond the end of the file. The size of the file does not increase until you call the SetEndOfFile, WriteFile, or WriteFileEx function. A write operation increases the size of the file to the file pointer position plus the size of the buffer written, which results in the intervening bytes uninitialized.

So once Notepad++ truncated a file it is possible that the other application would immediately grow it back with garbage.

[pnedev]

@gstavi ,

FYI SetFilePointer is not used anymore due to some network issues.
I could not understand what are you suggesting anyway, sorry.
My only point was that Wn32 API supports file shared access and despite the undoubtedly ‘good practice’ of not writing to file opened for writing by another process this behavior was restored because of the existing use cases and considering a change in this matter as ‘regression’ by the users.

BR

[pnedev]

@gstavi said in Deleting content from files also opened in other programs:

That was added by the patch I indicated. So I guess he is running as Admin.

I see your point, OK, but probably if he tries that with version 8.1.9.3 (or even 8.1.9.2) in Admin mode his log file write will succeed behaving like the old Notepad++ versions (before the Win32 file API addition).

[gstavi]

@pnedev
So far I was not suggesting anything. I was intrigued by @PeterJones initial comment about “honor filesystem locks” so I dug up the relevant patch and commented about it.

Then you pointed to the other issue so I browsed it as well.

While breaking user functionality is problematic, sometimes we should still consider it for the benefits of other users.

So my suggestion (and some change of mind on my part): I think that generally if a user is about to save a file that is in-use for write by another program then the user should be informed about it since it is a possible conflict with unforeseen side effects.
In my opinion, Notepad++ default should be to open a file without WRITE sharing to catch such errors. Then a user should be able to specify “forced save” where Notepad++ will try WRITE sharing. In any case that would only work if the other application allowed WRITE sharing as well.

I guess that the old APIs had WRITE sharing by default. But I think that could be considered an unsafe behavior.

[gstavi]

Notepad++ may have stopped using SetFilePointer but the other application may be using it, or async writes that provide write offset. So there is always a potential for a mess when 2 non-coordinated applications write to a file simultaneously.

[pnedev]

@gstavi ,

I couldn’t agree more. Writing to a file that has been open for writing by another process is definitely not a good idea. That’s why in my initial PR it was forbidden. But your suggestion is really great because this way we still give the user the possibility to overwrite the file while warning him upfront about the write access conflict. Excellent.
We should distinguish between file open failure due to write sharing violation or write permission failure so we either suggest ‘Force Save’ or ‘Admin Mode Save’. Perhaps GetError will help in that matter.