Disk Full error...on certain file and driectory create/copy methods

  • Thread starter Thread starter VJ
  • Start date Start date
V

VJ

I have these functions in my application.

FileInfo.CopyTo

DirectoryInfo.Create

File.Copy

Directory.Create

Do these methods generate a exception when the DISK is full were they are
trying to create a directory or copy a file? If so what is the exception?

VJ
 
* "VJ said:
I have these functions in my application.

FileInfo.CopyTo

DirectoryInfo.Create

File.Copy

Directory.Create

Do these methods generate a exception when the DISK is full were they are
trying to create a directory or copy a file? If so what is the exception?
Click to expand...

I didn't test it, but maybe an 'IOException'...
 
Hello, VJ:

You can test it using a diskette: Fill it with some files and then test the methods.
Under XP you can assign a user a very small disk quota and fill it for testing.

Anyway .NET doesn't handle disk full conditions very well. If it bothers you, you may test for enough free space before writing to disk.

Regards.


"VJ" <[email protected]> escribió en el mensaje | I have these functions in my application.
|
| FileInfo.CopyTo
|
| DirectoryInfo.Create
|
| File.Copy
|
| Directory.Create
|
| Do these methods generate a exception when the DISK is full were they are
| trying to create a directory or copy a file? If so what is the exception?
|
| VJ
|
|
|
 
Hi Jose,

that is clever
You can test it using a diskette: Fill it with some files and then test the methods.
Under XP you can assign a user a very small disk quota and fill it for
Click to expand...
testing.

Cor
 
Thanks, Cor.

I found something weird:

Class FullDiskTest
Public Shared Sub Main()
Dim arch As System.IO.FileStream
Dim a(511) As Byte
arch = New System.IO.FileStream("a:\che.bin", System.IO.FileMode.OpenOrCreate)
Try
arch.Seek(1300000, System.IO.SeekOrigin.Begin) 'Useful from the second time it runs...
Do
arch.Write(a, 0, 512)
Loop
Catch exc As System.Exception
System.Console.WriteLine(exc.ToString)
End Try
'Everything fine until now.
Try
arch.Close() 'Generates a Disk Full exception... and the file is not closed!
Catch exc As System.IO.IOException
System.Console.WriteLine(exc.ToString)
End Try
System.Console.ReadLine()
End Sub
'The program exits with an unhandled exception!
End Class


I have changed the arch.Close() line with theese others:
arch=nothing
System.GC.Collect() '(Generates an exception only inside the IDE)
System.GC.WaitForPendingFinalizers()

Theese last lines generate an unhandled exception (although they are inside the Try block).
The file is not unlocked until the program exits.
It seems to me that a Full Disk Exception is generated when the GC tries to close the file, but the GC doesn't handle the error, neither propagate it to the program.

Well, can anybody test it and tell me if it is the expected behavior?

Regards.


"Cor" <[email protected]> escribió en el mensaje | Hi Jose,
|
| that is clever
|
| >You can test it using a diskette: Fill it with some files and then test the
| methods.
| >Under XP you can assign a user a very small disk quota and fill it for
| testing.
|
| Cor
|
|
 
Hi Jose,

I think you are right.

I did also try it with the streamwriter, to be sure that it was not an
incident.

It seems if that if you try to close after that an error is thrown because
of a diskfull and the command is not executed and then when you try to end
your program, the framework tries again to close it automaticly but has no
room for it and you are even not able to undo your operation.

I did try to catch it in the closing and close event to be sure that there
was no escape and that was not working either.

Cor
 
* "Cor said:
It seems if that if you try to close after that an error is thrown because
of a diskfull and the command is not executed and then when you try to end
your program, the framework tries again to close it automaticly but has no
room for it and you are even not able to undo your operation.
Click to expand...

'StreamWriter' uses a buffer, that's why the error doesn't show up
directly when writing into the file. Calling the 'Close' method will
make data in the buffer persistent, then an error may occur.
 
Hi Herfried,

And what is the solution?

I did delete the close and then the error shows up direct, but what to
prevent the error but take some actions?

Cor
 
* "Cor said:
And what is the solution?

I did delete the close and then the error shows up direct, but what to
prevent the error but take some actions?
Click to expand...

If I would know a solution, I would have posted it.

;-)
 
Herfried,
If I would know a solution, I would have posted it.
Click to expand...

When I would thought that you had a solution for the problem, I did not have
asked this question, but I will prevent that Microsoft people think that
they don't have to document this bug (if we not see it wrong) and in some
answers from you (and maybe I do the same) it sometimes seems that the
problem is gone, while it is not..

This behaviour (not yours or mine) is very bad (the buffering is right as
you say, but that I can understand myself and even if it not was a buffer it
would have to write some file information if it really should closing).

The problem is not that you cannot write, the problem is that you cannot
prevent the try to write or let say it better to dispose the streamreader
object in a decent way.

Cor
 
Back
Top