Windows: Handling git better, not keep files open..

[stolsvik]

I use Glogg as a file viewer on windows, due to its extremely good handling of very large files.

From a Java project, we create some huge "report files" which are checked into git.

However, I do get some problems with git, as glogg evidently (quite obviously, given its "log viewer" main feature) keeps the files open. This works for the Java-task that writes to the file, as it evidently just truncs the file before writing a new report - nicely being caught by Glogg which reloads it instantly.

However, when handling the files with git (e.g. checkout, pull/rebase, whatever), it fails miserably, as git evidently unlinks (deletes) the file before putting in new content. This is not possible when glogg is active - and since I view these files all the time, this becomes a "oh, dang!" moment basically every single time I perform anything with git.

An (optional) feature where it would be possible to let Glogg not hold the file open, while still detecting changes and reloading, would for my use case be very valuable!

[nickbnf]

Thanks for the report, the only reason why glogg keeps the file open is performance. It is WAY slower to close and reopen the file every time glogg needs to redraw the screen. Interestingly this is what happened before 1.0.3 (see 90684c57709690a27f98f805e2b36754ca845348 where I did the change and mentioned some perf measurements). Note this is only a problem on Windows, sensible OSes like Linux or macOS don't care if a file is open when unlinking ("unlink" is actually a UNIX term, Windows deletes as I understand it). We could add an "advanced" option for Windows to keep the file closed, at the expense of performance.

[wiz0u]

This is a real issue for me as well. My logging system tries to rename or delete the daily log file at the end of the day but if someone is still watching the log file with the latest version of glogg, the file operation fails because the file is kept open by glogg. We had to revert to glogg 1.0.2 :(

[austinwagner]

I'd take slower performance over messing up log rotation because I kept a file open. Whatever the performance impact is, I doubt it will make it slower than the only other real competitor I've used: BareTail. Glogg has incredible search performance compared to BareTail which is the main reason why I'm dealing with the files being locked instead of using BareTail like everyone else at my workplace. I hope you consider adding that option to reopen the file on redraw instead of holding it open.

[shvez]

Windows allows to open file with delete access. one needs to specify FILE_SHARE_DELETE for CreateFile api call.

[austinwagner]

As far as I know that simply means that others who open the file handle with request for delete access won't be denied. The actual delete operation should still fail as long as any other handle to the file remains open.

On Feb 6, 2018 1:52 AM, "Ilya Shvetsov" notifications@github.com wrote:

Windows allows to open file with delete access. one needs to specify FILE_SHARE_DELETE for CreateFile api call.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nickbnf/glogg/issues/109#issuecomment-363328030, or mute the thread https://github.com/notifications/unsubscribe-auth/AAh9QOAW1TvhFQo-Av9Dn18Qd2vQ9hZXks5tR_awgaJpZM4H0p3K .

[shvez]

well, ok. here is from MS Docs:

The DeleteFile function fails if an application attempts to delete a file that has other handles open for normal I/O or as a memory-mapped file (FILE_SHARE_DELETE must have been specified when other handles were opened).

i do not have time to check it my self, although i do not see any sense to have right for operation which you can not complete anyway.

lets say, flag in settings will be einough.

[bilbothebaggins]

I can confirm from personal dev experience that FILE_SHARE_DELETE allows a file to be deleted (actually "deleted") while handles are open. The problem is, this won't help, because while the OS will honor the delete request once all handles have been closed, while the file is still being held, it's name is still there and not ready for reuse.

[GiuseppeGenga-Neural]

Hello @nickbnf, any news on the "don't keep the file open" option? I've got a similar issue with rotating Log4Net logs: if I keep them open in glogg, the rotation doesn't occur as the files are locked. I'll temporarily solve this forcing a glogg process termination on my client machine before the rotation time, but having an option would be great.

[wiz0u]

Please @nickbnf, add this as an option. Any serious company has a rolling/rotating/archiving log policy, and running instances of glogg preventing logs to be moved are just unacceptable. This feature is very important for glogg success.

[arushi315]

Hi @nickbnf Do you have any update on this issue? We are currently facing the similar issue mentioned by @wiz0u, rolling over fails since log file is locked by glogg.

[ssgonell]

As @wiz0u pointed out, version 1.0.2 has this feature (with some performance degradation though). I have switched to it given the cost benefit for my use case.

Quick link is here: http://glogg.bonnefon.org/files/glogg-v1.0.2-1-setup.exe

[variar]

I've implemented @wiz0u suggestion to fix variar/klogg#36. Need testing in real-world scenarios bacause my daily job does not involve log-files changing in real time. Latest builds are available from releases.