PC Toledo

Our final tests with Windows 10 Version 1709 (Fall Creators Update) revealed timing issues with the local file system, which may lead to changed application behavior as well as application runtime errors. In fact, all coding patterns which first delete a file on the local storage and then assume the file is gone may fail. This is valid for all programming languages used as the behaviour is introduced on the Windows API/file-system level. In other words, an FErase( "test.dbf" ) may lead to File( "test.dbf" ) == .T. in some but not all cases.

With that finding in mind we can not recommend updating production systems right now to Windows 10 Fall Creators Update. Our lab is working to get an idea if there is a way to fix or work around this behavior. For more details see PDR 6954.

By the way: all this reminds us about the infamous SMB2 design bug for which Alaska Software provided a fix on the Workstation side, which was downloaded by tens of thousands of Clipper, Visual FoxPro, Access and Office developers worldwide.

Resumindo:
Na nova versão do Windows 10, pode avisar que um arquivo que foi apagado ainda existe, além de problemas de tempo de resposta, chegando a gerar run-time error.

Comentário:
eu lembro que tive algo assim no Windows 7, mas o recurso de configurar o Windows que está incluso nos fontes do Harbour resolveu a questão.
Não sei se é o mesmo problema, ou se é um problema novo.
Apenas repassando, pra já servir de precaução caso aconteça algum problema parecido.

Ola!
O que vejo na pratica, é que o sistema operacional windows, do 95 até o 10, nada mudou para o usuário.
E que nestes casos, quem é pioneiro só faz pegar BUG's deles, que afetam os nossos programas para consertar.
Foi assim desde o CLIPPER com autoexec.nt etc... agora o SMB bugado do W10 e drivers de impressoras epson 350 que não funcionam e mais coisas que nem sabemos. Por isso só mudo de OS quando não tem mais jeito, ainda continuo com Win7 32/64, quem sabe mude do Win7 para o Win11 quando um dia ficar pronto.

Saudações,
Itamar M. Lins Jr.

Traduzido por:

http://tradukka.com/translate/en?hl=pt

Nossos testes finais com Windows 10 versão 1709 (atualização de criadores de queda) revelaram problemas de sincronismo com o sistema de arquivos local, o que pode levar a comportamento do aplicativo alterados, bem como erros de tempo de execução do aplicativo. Na verdade, todos os padrões de codificação que primeiro excluir um arquivo no armazenamento local e em seguida, assumir que o arquivo sumiu podem falhar. Isto é válido para todas as linguagens de programação usadas como o comportamento é introduzido no nível do Windows API/arquivo-sistema. Em outras palavras, um FErase ("test.dbf") pode levar ao arquivo ("test.dbf") = =. T. em alguns, mas nem todos os casos.

Com que encontrando-se em mente recomendamos pode não atualizar os sistemas de produção agora para atualização do Windows 10 queda criadores. Nosso laboratório está trabalhando para ter uma ideia, se houver uma maneira de corrigir ou contornar esse comportamento. Para mais detalhes veja 6954 PDR.

A propósito: tudo isso nos lembra sobre o bug de projeto SMB2 infame para que Alaska Software fornecido uma correção do lado da estação de trabalho, que foi baixado por dezenas de milhares de Clipper, Visual FoxPro, acesso e gabinete de desenvolvedores em todo o mundo.


Com este comando o que ocorreria Mister Quintas?
Obg. abs.

El problema es que la función DeleteFile del api de Windows no borra realmente el archivo hasta que todos los handles estén cerrados, aunque la aplicación los cierre correctamente con un closefile antes de borrarlo puede que quede algún handle del archivo pendiente a nivel del kernel del SO, y puede tardar algunos milisegundos para que el SO los libere, esto es un problema que se a reportado con otras versiones de Windows por algunos progradores en C.

Otro causa podría ser que en vez de usar las funciones del api de Windows para manejar archivos se utilice las funciones de C. El estándar establece que debe hacer las funciones de C pero no como se deben implementar por lo tanto puede haber diferencia entre compiladores para realizar una misma tarea, la mayoría de los compiladores de C utilizan servicios de bajo nivel del SO para manejar los I/O y puede que en algún caso exista algún delay en la sincronizacion con las funcionalidades de alto nivel del SO.
Las funciones de archivos de más alto nivel de C como fopen, fwrite,etc utizan un buffer interno propio de C, y no se descargan hasta que el buffer se llene, se lo obligue a descargar ej. fflush, o se cierre con fclose. Por lo tanto inmediatamente de un fclose puede que todavía el archivo este abierto porque el buffer se esta descargando a disco. Lo que en general se usa aveces es un tipo de bucle en el cual se intenta borrar el archivo un numero determinado de veces con algun tiempo de espera entre ellos antes de reportar el error al usuario.

En resumen es probable que el file() de hb retorne .t. porque realmente el archivo todavía no ha sido borrado realmente por el SO.

Gracias mister Soto, excelente explanación. Comprendo perfecto! No tengo el que decir sobre el tema, pués uso Fivewin for xHarbour y no tengo ningúm problema informado por los usuários de mi app. Muchas gracias. Saludos.