Hi Lee, On Fri, Dec 20, 2013 at 10:23 PM, Lee Winter <[email protected]>wrote:
> Recently I've been trying to use debug tools to understand what > happens to a software tool that is invoked by tup. But the > .tup/mnt/@tupjob-#/ directories have been impenetrable. > > In fuse_fs.c I've disabled the pgid check so that other process groups > should be able to access the fuse directories in the same way the > tup-launched software tool accesses those directories. > How did you disable the pgid check? I tried to just do a 'return 0;' in context_check() and I am able to access the .tup/mnt directory. Doing 'ls .tup/mnt' should show the root file-system, as should 'ls .tup/mnt/@tupjob-X'. > > However, I'm not able to see or access anything under .tup/mnt/ from > other contexts. > > I'm certain that the directories exist because a build tool that > prints pwd or navigates around the fuse file system does have > apparently normal access to the whole fuse directory tree. > > Why is it that other tools, not launched by tup, cannot even detect > the existence of the directories under .tup/mnt/? > Just a quick sanity check - you do have tup running while you do this, right? The file-system is mounted on demand when running an update, and unmounted when tup exits. Probably the easiest way to check is to add a command that does a 'sleep 50' or some large number so that you have time to poke around the file-system. What are you ultimately trying to determine? Aside from the @tupjob paths appearing in pwd, is there something not behaving as you would expect? Thanks, -Mike -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
