Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
From: =?utf-8?Q?Konstantin_Prei=C3=9Fer?= <verlag.preisser@t-online.de>
To: "'Tomcat Users List'" <users@tomcat.apache.org>
References: <51E5BE91.8010800@yahoo.com>
In-Reply-To: <51E5BE91.8010800@yahoo.com>
Subject: RE: [OT] Cannot cleanly undeploy a web application
Date: Wed, 17 Jul 2013 15:15:38 +0200
Message-ID: <000001ce82ef$bb73dbd0$325b9370$@t-online.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQEJyKUryDbfpLIZCuE08SsmOiKEEJryR/+A
Content-Language: de

Hi,

> From: Andr=C3=A9 Warnier [mailto:aw@ice-sa.com]=20
> Subject: Re: [OT] Cannot cleanly undeploy a web application
>=20
> I believe that the underlying issue here is the difference in =
behaviour between Windows=20
> and Unix/Linux, with regard to a file opened by one process, when =
another process tries to
> delete the file.
> Unix/Linux allow this. The file entry in the directory is deleted, the =
process deleting it
> gets no error. The file itself is not deleted, and the process which =
has it open still has
> a handle to the file and can continue to access it.
> Under Windows however, the process trying to delete the file gets an =
error, at the very=20
> moment of the "delete".

I just wanted to add something:

The Unix behavior you describe is also possible under Windows. It =
depends on the "file share" flag that is used to open a file.
I don't know how this works in the native WinAPI, but if you try the =
following C# code for example (.Net) to read from a (big) file:

using (Stream s =3D new FileStream("C:\\MyBigFile.bin", FileMode.Open, =
FileAccess.Read, FileShare.Delete | FileShare.Read)) {
    byte[] buf =3D new byte[128];
    int read;
    while ((read =3D s.Read(buf, 0, buf.Length)) > 0) {
        Console.WriteLine("Read: " + read + " bytes.");
        Thread.Sleep(2000); // wait 2 seconds
    }
}

Then you can delete the file while it is still opened and the program =
reads from it. If you look at the free space of the drive, you will see =
that the space that the file uses is not yet available. As soon as you =
close the process / cancel the reading, the space will become available.

It seems that most programs don't open a file that way - that is why an =
error occurs when trying to delete such a file. However, I don't know =
why most programs (or a Java InputStream etc.) open a file for reading =
without specifying such a file share flag (E.g., in the above code =
example, if you use a FileStream constructor that doesn't specify a =
FileShare flag, the file cannot be deleted from other processes while it =
is opened). Maybe it is a design principle in Windows to not be able to =
delete a opened file by default, so that a user doesn't accidentally =
delete a file on which he is still working... but I don't know.


Regards,
Konstantin Prei=C3=9Fer


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org