Clipper On Line • Ver Tópico - Alerta recebido do pessoal do xBase++

Alerta recebido do pessoal do xBase++

Projeto Harbour - Compilador de código aberto compatível com o Clipper.

Moderador: Moderadores

 

Alerta recebido do pessoal do xBase++

Mensagempor JoséQuintas » 19 Out 2017 11:03

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.
José M. C. Quintas
Harbour 3.2, mingw, gtwvg, multithread, dbfcdx, ADO+MySql, PNotepad
"The world is full of kings and queens, who blind our eyes and steal our dreams Its Heaven and Hell"

https://github.com/JoseQuintas/
Avatar de usuário

JoséQuintas
Membro Master

Membro Master
 
Mensagens: 18014
Data de registro: 26 Fev 2007 11:59
Cidade/Estado: São Paulo-SP
Curtiu: 15 vezes
Mens.Curtidas: 1206 vezes

Alerta recebido do pessoal do xBase++

Mensagempor Itamar M. Lins Jr. » 20 Out 2017 11:00

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.
Avatar de usuário

Itamar M. Lins Jr.
Colaborador

Colaborador
 
Mensagens: 6927
Data de registro: 30 Mai 2007 11:31
Cidade/Estado: Ilheus Bahia
Curtiu: 309 vezes
Mens.Curtidas: 503 vezes

Alerta recebido do pessoal do xBase++

Mensagempor Kapiaba » 20 Out 2017 11:10

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?

   DELETEFILE( cDirExe + "GERAPNFE.Log" )


Obg. abs.
Kapiaba
Colaborador

Colaborador
 
Mensagens: 1765
Data de registro: 07 Dez 2012 15:14
Cidade/Estado: São Paulo
Curtiu: 310 vezes
Mens.Curtidas: 119 vezes

Alerta recebido do pessoal do xBase++

Mensagempor Claudio Soto » 20 Out 2017 14:35

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.
Saludos.
Dr. Claudio Soto
(Uruguay)
http://srvet.blogspot.com
Avatar de usuário

Claudio Soto
Colaborador

Colaborador
 
Mensagens: 555
Data de registro: 27 Ago 2012 12:31
Cidade/Estado: Uruguay
Curtiu: 35 vezes
Mens.Curtidas: 166 vezes

Alerta recebido do pessoal do xBase++

Mensagempor Kapiaba » 20 Out 2017 14:52

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.
Kapiaba
Colaborador

Colaborador
 
Mensagens: 1765
Data de registro: 07 Dez 2012 15:14
Cidade/Estado: São Paulo
Curtiu: 310 vezes
Mens.Curtidas: 119 vezes




Retornar para Harbour

Quem está online

Usuários vendo este fórum: Google [Bot], Jamil e 6 visitantes


Ola Amigo, espero que meu site e forum tem lhe beneficiado, com exemplos e dicas de programacao.
Entao divulgue o link da Doacao abaixo para seus amigos e redes sociais ou faça uma doacao para o site forum...
MUITO OBRIGADO PELA SUA DOACAO!
Faça uma doação para o forum
cron
v
Olá visitante, seja bem-vindo ao Fórum Clipper On Line!
Efetue o seu login ou faça o seu Registro