Eu sou o segundo fredarin. Um dupe de uma resposta que eu postei no SO:
0 votos para baixo
Se você verificar a fonte glassfish, especificamente ./appserv-commons/src/java/com/sun/enterprise/util/io/FileUtils.java, você verá todas as contorções pelas quais o Glassfish passa, a fim de excluir / renomear arquivos e diretórios no Windows.
Este é um problema do Windows, com suas restrições para excluir e renomear arquivos abertos.
Existem todos os tipos de truques, incluindo a solicitação de um GC da JVM várias vezes, na esperança de fechar o fluxo de arquivos, os loops de "pseudo" renomeação, sleep-try.
Alguns exemplos:
/**
*Attempts to delete files that could not be deleted earlier and were not overwritten.
*<p>
*On Windows, the method requests garbage collection which may unlock locked
*files. (The JarFile finalizer closes the file.)
/*
*On Windows, as long as not all leftover files have been cleaned and we have not
*run the max. number of retries, try again to trigger gc and delete
*each remaining leftover file.
*/
/**
* Windows has BIG issues renaming a directory that is open somnewhere -- e.g. if
* a DOS box is opened anywhere in that directory.
* This method will try to do a "virtual renaming" if there are problems
* I.e. it attempts to do a simple rename, if that fails it will copy everything under
* the original directory to the renamed directory. Then it will delete everything
* under the original directory that the OS will allow it to.
Na prática, isso às vezes se traduz em implantações ou reimplementações no Windows, pois alguns arquivos não podem ser excluídos ou movidos e acabam sendo deixados para trás. De todas as instâncias do Glassfish que eu executo, eu nunca tive um problema no Solaris 10 e sempre tenho problemas relacionados a isso no Windows.
Em suma, qualquer * NIX será melhor apenas por esse motivo, deixando de lado outras considerações sobre o administrador da plataforma.