[DGD]File system bug

[Jason Cone]

Greets.

> I see no file descriptor/handle leaks in relevant places.  If memory of
> Windows file system semantics serves me correctly, it is impossible to
> remove a file that has just been created and is still open for writing.

Correct.  The issue here, though, is not of removing a file, but rather a
directory.  The following would prevent the removal of a directory:

* It is currently the root or current working directory.

* A handle to a _findfirst (or FindFirst, if using the Win32 API) operation has
not been closed with a _findclose call.

* The directory is not empty.

I'm sure there are others, but those are the most common culprits.

> Also, the file should show up with length 0 in a directory listing until
> the descriptor has been closed.
>
> If Windows 2000 has some new file recovery thingy, now is the time to turn
> that off.  In the meantime,
>
> What version of DGD?

1.1.70

> What filesystem type, DOS or NTFS?

The problem originally surfaced on NTFS, but after creating a FAT32 partition on
the same machine and rerunning the test, the same thing happend.

> Can you remove the directory after you fully quit and restart DGD?

I probably should have started off the message with this, but oh well. ;)  After
some tests, I've found that the actual problem is one of directories, not files,
and is demonstrated by the following:

1) make_dir("/foo/bar");
2) get_dir("/foo/bar/*");
3) remove_dir("/foo/bar");

[The above assumes that "/foo" exists and that "/foo/bar" doesn't befire
make_dir() is called]

remove_dir(a); fails.  If I remove the get_dir(a + "/*"); call, however,
remove_dir(a); is successful.

In a more practical sense, I added the following code segment to my driver's
initialize() function:

if (!make_dir("/test/test"))
{
    send_message("Could not create the directory.\n");
}

get_dir("/test/test/*");

if (!remove_dir("/test/test"))
{
    send_message("Could not remove the directory.\n");
}

send_message("Test is complete\n");

The above, of course, assumes that "/test" exists and that "/test/test" does
not.  As it is, the above code results in a failed attempt to remove the
directory.  If I comment the get_dir() line out, though, the directory is
removed without error.  If I replace the '/test/test/*' in the get_dir() call
with something that does _not_ reference the '/test/test' directory (ie.,
'test/*'), it works fine as well.  My conclusion is that the error occures when
trying to get file information that involves '/test/test' to any extent
('/test/test/blah' results in failed remove_dir(), as well).

I put debug messages in both ./src/kfun/file.c and ./src/host/pc/dosfile.c in
some suspect parts, but found nothing that would justify a failed _rmdir() call.
This was at 3 am this morning, so I wouldn't put too much faith in the fact that
I didn't find anything wrong. :)  Anyway, I hope this helps a bit more.  I'm
about to run the same tests on an NT 4 machine and see if get the same
results...

Jason

--
  Jason Cone
  Senior Software Developer
  Usability Sciences Corporation
  jcone at usabilitysciences.com


List config page:  http://list.imaginary.com/mailman/listinfo/dgd