The original problem is that compiling stuff with djgpp corrupts recently created files in a crosslinked way on my harddisk, unless I put the temp directory on a ramdisk where I don't care what happens. But because problem is probably too hard to debug, I've made a somewhat easier test case.
I'll attach a bootable raw 1.44 floppy disk image with freedos kernel 2040, and files from the freedos 1.1 iso, along with two test cases with c source, when this bug report goes through for the third time now. The sources were compiled width gcc 4.7.0. Before each test please write out the image again to start from a clean state. Virtual machine makes this faster.
1. After boot run a.exe
2. Now check filesystem by running "dosfsck -a a:". 20 clusters are reclaimed.
3. Run a.exe again
4. Execute "echo test >test2"
5. Now check filesystem by running "dosfsck a:". Nice crosslinked files...
Do the same as test1, but with b.exe. Except there are no crosslinked files this time, only lost clusters.
It could be that I expect too much from DOS regarding safe opening of files multiple times, so for the next tests let's start "share.exe" before running them, which is exactly what I would expect to mitigate this problem.
Same as test1, with share. Finally no crosslinked files, only lost clusters. Not perfect, but ok. Unfortunately it still crosslinks on my harddisk sometimes, but at least on this disk image it's ok.
Same as test2, with share. Wow, no corruption at all, but this was the easier test ;(
Unfortunately using "share" when doing the original djgpp compilation case does not solve the crosslinked file problem. But who knows maybe fixing this smaller bug could also solve the djgpp problem. Or fixing "share" itself does.
I've tried kernel back to 2034, 2038, 2039, 2040, 2041, and I just couldn't find one which would not corrupt the filesystem for the djgpp compilation, so I don't think this is a regression.
Log in to post a comment.