Olaf Meeuwissen writes:
> Hi all,
>
> I've been chasing a bug where the epson2 backend prevented another
> backend from recognizing that backend's supported network scanners.
> Turns out that the epson2 backend holds on to file descriptors (and
> associated network connections) even if it decides that the device is
> one that the epson2 backend doesn't support after all.
>
> Upon closer inspection, not only network connections were affected but
> *any* connection that used a file descriptor. Attached is a patch.
This issue popped up in sane_get_devices() so closing file descriptors
for devices a backend decides it does not support after all is a good
neighbourly thing to do. What is less clear cut, is what should be done
with the file descriptors for devices that a backend does support.
In my particular scenario not closing the file descriptor would prevent
an alternative backend from recognizing the device as supported if its
sane_get_devices() is run after the epson2 one. If their respective
sane_get_devices() are called the other way around, both backends might
be able to recognize the device as supported (if the alternative backend
closes all its file descriptors).
So my question really boils down to whether backends must/should close
any file descriptors opened as a result of calling sane_get_devices().
Thoughts, anyone?
--
Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION
FSF Associate Member #1962 Help support software freedom
http://www.fsf.org/jf?referrer=1962
