Fossil SCM
RECONSTRUCT failure
d752140c7a4ccce…
· opened 12 years, 2 months ago
- Type
- Code_Defect
- Priority
- —
- Severity
- Severe
- Resolution
- Fixed
- Subsystem
- —
- Created
- Feb. 2, 2014 9:57 p.m.
RECONSTRUCT fails on Win7 (64-bit) with message "cannot open ??? for reading" where ??? is the filepath. Previous versions (1.27) work fine.
Comments (12)
RECONSTRUCT fails on Win7 (64-bit) with message "cannot open ??? for reading" where ??? is the filepath. Previous versions (1.27) work fine.
RECONSTRUCT fails on Win7 (32-bit & 64-bit) with message "cannot open ??? for reading" where ??? is the filepath. Previous versions (1.27) work fine.
Well, the "reconstruct" command, implemented in src/rebuild.c didn't change basically, I cannot reproduce neither explain it. Did you compile from source or are you using the downloaded .exe? How does your path look like? It it on an external drive?
I used the downloaded prebuilt EXE.
The problem is there in all fossil files I have (about 6 of them, from 1 to 12MB each). But since I cannot provide any of those, I'm trying to make a different one that shows the problem.
I tried with a new file containing only a couple of files and it didn't show a problem. So, I guess it has to be something more complex that triggers this. Give me some time, and I'll come back with an example file.
OK, rather than trying to come up with a test case, I tried with the SQLite fossil file, and the problem is there. (I know it's not the smallest possible test case, but at least it shows the problem.)
To reproduce the problem, run the following commands from the Win7 DOS prompt:
fossil clone http://www.sqlite.org/cgi/src sample.fossil md somedir fossil dec somedir -R sample.fossil fossil rec new.fossil somedir
The output from the above is:
C:\Temp>fossil clone http://www.sqlite.org/cgi/src sample.fossil Round-trips: 6 Artifacts sent: 0 received: 49495 Clone finished with 1469 bytes sent, 29081473 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: 2ab58778c2967968b94284e989e43dc11791f548 admin-user: Tony (password is "8b2d69")
C:\Temp>md somedir
C:\Temp>fossil dec somedir -R sample.fossil 100.0% complete...
C:\Temp>fossil rec new.fossil somedir Reading files from directory "somedir"... 205 cannot open somedir/00 for reading
C:\Temp>
Hope this helps!
I don't know why the formatting was messed up. Here are the commands again.
fossil clone http://www.sqlite.org/cgi/src sample.fossil
md somedir
fossil dec somedir -R sample.fossil
fossil rec new.fossil somedir
BTW, I just checked under Ubuntu Linux and the same file that breaks FOSSIL under Win7 works fine.
Hi! There is a potential fix in [8e110293edfa93c6b2da7f45bbc76f5f782ef728]. Please try that out and let us know. Thanks for your extremely detailed report - it made localizing that problem simple. That said, that fix might not have been the source of your specific woes (but it's at the same code spot) - we won't know until you can try it out.
Ticket author has been notified by email.
Author responded via email - problem is still happening :(. Looking at the code, i can see no reason for it.
[I'm afraid I was misunderstood. I did not say the problem is still there. I said I cannot compile the version with the changes you proposed because the given build process is faulty, or does not work as given (on two different PCs I tried). I suppose the actual Windows version available for download is produced from Linux by cross-compilation, and not compiled on a Windows PC, and so the makefiles are not tested in 'real life' from a Windows PC.
Regarding compilation, I used the USE_WINDOWS conditional in the makefile.mingw32 but I still get the following error during compilation:
gcc -o wbld/makeheaders src/makeheaders.c
mingw32-make: *** No rule to make target 'src/../manifest.uuid', needed by 'wbld /VERSION.h'. Stop.
If anyone can help with get a clean AND working compilation from a Windows PC using MinGW, I'm all ears. Sorry for the confusion.]
Regarding this ticket, I noticed the original problem with the precompiled EXE but since I cannot recompile myself, I cannot test your changes. My compilations always crash, irrespective of the bug fix being applied or not, simply because the compilation process does not produce a proper EXE.
I tested the latest? [4adcd4f4f5] with a VC compiled copy (which -- unlike the MINGW makefile -- compiles without any problems) and both DEC and REC work great. So, I consider this fix did the trick.