#93 Crosslinked files, possibly truncate

open
Kernel (32)
5
2012-05-29
2012-05-29
No

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.

Test 1:
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...

Test 2:
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.

Test 3:
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.

Test 4:
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.

Discussion

  • dos386

    dos386 - 2012-06-16

    > It could be that I expect too much from DOS regarding safe opening of files multiple times

    IIRC this is a known flaw of every DOS.

    > I've tried kernel back to 2034, 2038, 2039, 2040, 2041

    Try with EDR-DOS too (preferred FreeDOS kernels: 2041 2040 2038).

    Does this happen with older DGJPP too ?

     
  • Soci/Singular

    Soci/Singular - 2012-06-16

    I understand that proper write sharing of files is a complex matter and it's not supported on DOS.

    But instead of trashing the filesystem it would be better to return an error for the second open or write attempt. Like if the file would be write protected or so.

    This might be a DJGPP bug as well, but damaging the file system beyond just lost clusters using just normal file level calls feels like a bug in the OS too. This is not raw access after all.

     
  • dos386

    dos386 - 2012-06-16

    > But instead of trashing the filesystem it would be better to return an
    > error for the second open or write attempt. Like if the file would be write
    > protected or so.

    Agree. But no existing DOS does. Most likely this is also the
    reason for "can't copy file to itself" argument :-D

    > This might be a DJGPP bug as well

    Please report it in the DGJPP group.

    > but damaging the file system beyond just
    > lost clusters using just normal file level calls feels like a bug in the OS

    A well known horrible flaw. Please suggest the "protection" in
    the FreeDOS mailing list. FreeDOS can get a "feature" that no other DOS has.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks