On Mon, Mar 11, 2019 at 12:20:43AM +0200, Ciprian Dorin Craciun wrote: > On Mon, Mar 11, 2019 at 12:06 AM Benjamin Kaduk <ka...@mit.edu> wrote: > > To be clear, they do share a great bit of code (dafs was not "from > > scratch"), but there are many places that do get differential treatment in > > the source -- look for AFS_DEMAND_ATTACH_FS preprocessor conditionals. > > > Based on what I see: > > https://github.com/openafs/openafs/search?q=AFS_DEMAND_ATTACH_FS > > https://github.com/openafs/openafs/blob/c1d39153da00d5525b2f7874b2d214a7f1b1bb86/src/viced/Makefile.in#L15 > > https://github.com/openafs/openafs/blob/c1d39153da00d5525b2f7874b2d214a7f1b1bb86/src/dviced/Makefile.in#L15 > > I would assume that most of the code is common (in terms of files), > and at compile time the sources are re-built with different defines.
That's correct. But it's easy for code to *compile* but still behave badly at runtime. > Thus I think that when one would modify the code, in large part the > code is common, and where it isn't at least the "switch" is visible in > there. Therefore I'm confident that the `fileserver` is still a > viable solution. :) I won't really dispute that it is viable at present, but it's pretty clear to me that it's no longer a *recommended* solution, and I don't really understand your attachment to it. Is this just because you continue to investigate running a simple fileserver without the bosserver and demand-attach has more moving parts in that respect? Thanks, Ben _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info