Yes, I was think about something like that. As an initial experiment, I tried to used flfmt with the -v option on a vac archive just to see the result. It seems that the vac archive does not contain the max qid that flfmt needs. This seems strange to me, as vac -a should need this info just as much as fossil needs it. Maybe it's tucked away somewhere else. Guess I need to look some more at the code.
ole@ole-TECRA-R940 ~/Desktop/plan9 $ bin/fossil/flfmt -h 192.168.0.101 -v f648dbae0075eb73bc394ad6cd4c059e655e127c fossil.dat
fs header block already exists; are you sure? [y/n]: y
fs file is mounted via devmnt (is not a kernel device); are you sure? [y/n]: y
0xfb1e734c
0x1d1feaf1
c85978546e4048fce83120d3992cfc2f57ff2f8c
bin/fossil/flfmt: bad root: no qidSpace
/*
* Maximum qid is recorded in root's msource, entry #2 (conveniently in e).
*/
ventiRead(e.score, VtDataType);
if(!mbUnpack(&mb, buf, bsize))
sysfatal("bad root: mbUnpack");
meUnpack(&me, &mb, 0);
if(!deUnpack(&de, &me))
sysfatal("bad root: dirUnpack");
if(!de.qidSpace)
sysfatal("bad root: no qidSpace");
qid = de.qidMax;