On 28/10/17(Sat) 13:57, Helg Bredow wrote: > [...] > I've reverted fuse_loop_mt(). However, I don't feel that this is correct. If > a file system expects it to work then it should fail to make it clear that > the functionality is not implemented. sshfs calls it but because > fuse_parse_cmdline() always returns 0 for multithreaded it never gets called > (you normally need to specify -s on the command line for multithreaded fuse > file systems to run in a single thread. I've tested to see what sshfs does > when fuse_loop_mt() returns -1 and it simply exits with no message, just as > it does when it returns 0.
I agree it's incorrect. But sometimes correct changes introduce regressions. So it's simpler to not mix such change with a bigger one like the NULL checks in case we need to revert them. > I also reverted the version macro change. The value for both macros is the > same (26) and they will likely stay in step if the version is incremented. > It's not using the correct macro though. I'd be happy to see you commit these changes now that the NULL checks are in :) > > We can remove fuse_is_lib_option() if nothing in ports use it. A good > > start to search for it is codesearch.debian.net. You can also ask > > porters to do a grep on unpacked port tree. > > > > I didn't know about this site, it will be useful. I was going to search the > ports source tree but this saves me the trouble and also expands the search. > sshfs calls this fuse_is_lib_option() so it will have to stay. However, it > also needs work as it doesn't behave the same as the Linux version. The nice thing is that we can do test-driven development using the linux version as reference (8 > > Could you provide a diff including only the NULL check and the removal > > of "unused" markers? > > > > Updated patch is below. That's in now.
