concerned about the security of well-known file names being used. i dont know all the implications and i did not read your code, but various symlink attacks might be possible. other apps deal with this of course, make sure to take a look at how they do it. also, is it possible to use flock() on the device files instead/as well?
allan On Mon, 7 Feb 2005, Gerhard Jaeger wrote: > Hi, > > On Monday 07 February 2005 12:41, Johannes Meixner wrote: >> >> Hello, >> >> On Feb 7 12:11 Gerhard Jaeger wrote (shortened): >>> The idea is to provide a simple locking mechanism for the backends, >>> to have exclusive access to one scanner during an operation: >> ... >>> What do you guys think of this lib - is it useful? >> >> I even think exclusive access should be used by default >> because I think normally it doesn't make sense when there >> is more than one process which talks to the same scanner >> (i.e. "the same scanner" but not "the same backend" because >> one backend can drive several scanners). > > I agree! Each device a backend talks to needs some exclusive > locking! > >> >> Once it happened while I did a nice (you may say stupid) stress test >> >> for i in $( seq 100 ) >> do sane-find-scanner & scanimage -L & >> done >> >> that one of my USB scanners made funny noise: It seems it tried >> to move its scanning unit beyond its physical limits. >> I have no idea how this could have happened but I guess the scanner >> was simply totally confused by the multiple concurrent accesses. > > It should not happen, but even such stupid tests show, that the locking > needs to be done in another way, as it's currently done, if it's done. > Rather the same "confusion" will happen when you have something > like Rene Rebes' button daemon which does nothing else than checking the > button status of a scanner - depending on the scanner, the backend needs > to check some or at least one register and when another frontend currently > is scanning - the scanner will not work properly afterwards (highly depends > on that device) > >> >> By the way: >> The reason for the above stress-test was that this way I could >> stop the kernel (no single error message in the logs - just a >> sudden stop) - meanwhile I do no longer use the crap SCSI >> host adapter ;-) > > This test should become another stress-test for a new backend ;) > > > Ciao, > Gerhard > > > -- "so don't tell us it can't be done, putting down what you don't know. money isn't our god, integrity will free our souls" - Max Cavalera
