Gerdriaan Mulder

This may seem related to #147, but the gist here is that we actually want to capture these warnings (although any other method of detecting 'incomplete' or 'corrupt' images would...

Hi @tonimelisma, thanks for replying. To clarify with regards to the output of the `vips` command: ``` $ vips copy 7.jpg x.v (vips:3573083): VIPS-WARNING **: 10:46:28.748: read gave 1 warnings...

I've recompiled libvips 8.10.5 with debugging information. A gdb backtrace gives somewhat more information, now. ``` user@host:/tmp/libvips-8.10.5/vips-8.10.5$ LD_PRELOAD=libvips/.libs/libvips.so.42 G_DEBUG=fatal-warnings gdb ./tools/.libs/vips [..] Reading symbols from ./tools/.libs/vips... (gdb) set args copy...

The warnings are emitted in [`readjpeg_free`](https://github.com/libvips/libvips/blob/v8.10.5/libvips/foreign/jpeg2vips.c#L312-L336). [Closing](https://github.com/davidbyttow/govips/blob/v2.7.0/vips/image.go#L323) an image in [`govips`](https://github.com/davidbyttow/govips/blob/v2.7.0/vips/image.go#L323) eventually [calls](https://github.com/davidbyttow/govips/blob/v2.7.0/vips/image.go#L1280) [`g_clear_object(image)`](https://github.com/davidbyttow/govips/blob/v2.7.0/vips/image.c). It seems to me that `govips` does not follow the same code path as `vips` itself...

I've made a start by looking how `libvips` describes their [reference counting](https://www.libvips.org/API/current/using-from-c.html#using-C-ref). The following diff in `govips` sets a small step in the right direction, along with a slightly adjusted...

Apart from the stack trace (which is added in `error.go:handleVipsError()`), the diff posted above seems stable enough. `make test` ran fine, output of `go test` (without verbosity): ``` $ CGO_CFLAGS_ALLOW=-Xpreprocessor...

Just a thought. The wiki page referenced [here](https://github.com/phillipberndt/autorandr/issues/213#issuecomment-641297750) was last updated in 2016. [The last release of pydbus (v0.6.0)](https://github.com/LEW21/pydbus/releases/tag/v0.6.0) is equally old, and as far as I can tell, there...

> It does some of it. > > Getting the screen events: > `dbus-monitor --system "type='signal',path=/org/freedesktop/UPower"` > > Getting the monitor events: > `dbus-monitor --system "type='signal',path=/org/freedesktop/ColorManager"` > > The output...

In `filename_detector.go`, there is a pattern that literally says `password`, therefore any filename that contains the word `password` will match. In `pattern_detector.go`, there are extra rules for what should surround...

As far as I can tell, it does check _inside_ the file, but the patterns for filenames and contents are different. Perhaps try it with a test2.txt containing: ``` password=hunter123...