Problema com File() & Upper/Lowercase

[JoséQuintas]

Uso multithread. Até pra não ter problema de configuração, criei uma função com os Sets, incluindo os de Upper/Lower.

Código: Selecionar todos

FUNCTION InitSets()
   Set( _SET_FILECASE, 2 )
   Set( _SET_DIRCASE, 2 )
   RETURN NIL

Fui fazer uma alteração hoje, pra usar multipastas, e passei a ter o que considero um "problema do carvalho" ( ou do "quintas" mesmo ).
Criei esta função, que conforme o nome do arquivo vai acrescentar um path diferente.
Acabei de criar, só tem referência a jpcidade e nenhum outro.

Código: Selecionar todos

FUNCTION PathAndFile( cNome )
   cNome := Lower( cNome )
   IF cNome $ "-jpcidade-"
      cNome := AppCommonFolder() + cNome
   ENDIF
   RETURN cNome

Acontece que na hora de checar existênca de CDX, File() retorna .F.

Código: Selecionar todos

File( PathAndFile( cDbf ) )

Se na função PathAndFile() eu acrescentar Upper() funciona.
E isso acontece pra todos os arquivos, não somente pra jpcidade.
Isso significa que os nomes estão corretos, nenhum caractere a mais, mas parece que os Sets() não estão sendo obedecidos.

Harbour 3.2, gtwvg, multithread, Windows 7 64 bits.

No momento sem idéia do que mais procurar.
Já pesquisei a chamada da função dos Sets() e está em cada thread.

[Toledo]

José, estes Sets (FILECASE e DIRCASE) só funcionam em sistema operacional que é "case sensitive", que é sensível a maiúsculas e minúsculas. No caso do Windows, não é case sensitive.

Outra observação... você não mostrou o conteúdo de "cDbf", mas acho que seja no formato NomedoArquivo.Ext (.extensão), então o comando IF cNome $ "-jpcidade-" nunca será verdadeiro, e assim o file() vai procurar o arquivo na pasta local, ai resta saber se o arquivo realmente existe na pasta local.

Em tempo:

Código: Selecionar todos

   Set( _SET_FILECASE, 2 )
   Set( _SET_DIRCASE, 2 )

O parâmetro 2 representa UPPER.

Abraços,

[JoséQuintas]

Continuo testando, afinal, é a rotina de checagem de índices do meu sistema, e não dá pra ficar sem ela.
Até postei nos desenvolvedores.
E isso me lembra aqueles bugs do File() que já aconteceu com mais de uma pessoa.
Segue o post nos desenvolvedores, mais completo porque fiz mais testes hoje:


it's a crazy bug.

Routine:

Código: Selecionar todos

   IF .NOT. UpperFile( PathAndFile( cDbf ) + ".CDX" )
      SayScroll( "Não encontrou " + PathAndFile( cDbf ) + ".CDX" )
      Inkey(3)
      ...
  ENDIF
...
FUNCTION PathAndFile( cFileName )
   cFileName := Lower( cFileName )
   SayScroll( "FileName " + cFileName )
   IF cFileName $ "-jpcidade-"
      SayScroll( "Entrou no IF" )
      cFileName := AppCommonFolder() + cFileName
      SayScroll( "Novo nome" + cFileName )
   ENDIF
   RETURN cFileName

FUNCTION UpperFile( cFile )
   LOCAL lAchou := .T., cTexto
   DO CASE
   CASE File( cFile )
   CASE File( Upper( cFile ) )
      cTexto := "Falhou File(" + cFile + ") e funcionou File(" + Upper( cFile ) + ")" + HB_EOL()
      cTexto += "Set( _SET_FILECASE ) = " + Transform( Set( _SET_FILECASE ), "" ) + HB_EOL()
      cTexto += "Set( _SET_DIRCASE ) = " + Transform( Set( _SET_DIRCASE ), "" ) + HB_EOL()
      WriteErrorLog( cTexto, 2 )
   CASE hb_FileExists( cFile )
      cTexto := "Falhou File(" + cFile + ") e funcionou hb_FileExists(" + cFile + ")"
      cTexto += "Set( _SET_FILECASE ) = " + Transform( Set( _SET_FILECASE ), "" ) + HB_EOL()
      cTexto += "Set( _SET_DIRCASE ) = " + Transform( Set( _SET_DIRCASE ), "" ) + HB_EOL()
      WriteErrorLog( cTexto, 2 )
   OTHERWISE
      lAchou := .F.
   ENDCASE
   RETURN lAchou

If I remove IF...ENDIF from PathAndFile() all works ok.
if I add a line with cFileName := Upper( cFileName ) in PathAndFile() all works ok. (don't enter in IF for any file)
But if..endif modify only one filename, not all filenames, I add messages to make a debug and confirm this.
At momment I don't know what to do.

partial log

FileName jpbarra
FileName jpcadas
FileName jpcadas
FileName jpcadas
FileName jpcadas
Não encontrou jpcadas.CDX
FileName jpcadas
FileName jpcadas
FileName jpcadas
FileName jpcidade
Entrou no IF
Novo Nome..\jpcidade
FileName jpcidade
Entrou no IF
Novo Nome..\jpcidade
FileName jpcidade
Entrou no IF
Novo Nome..\jpcidade
FileName jpcidade
Entrou no IF
Novo Nome..\jpcidade
FileName jpclista
FileName jpclista
FileName jpclista
FileName jpclista
Não encontrou jpclista.CDX
FileName jpclista
FileName jpclista
FileName jpclista
FileName jpcomiss
FileName jpcomiss
FileName jpcomiss
FileName jpcomiss
Não encontrou jpcomiss.CDX

Looking the log:
- only jpcidade enter in IF
- no other filename is changed (then remove if..endif don't change other filenames)
- CDX exists in folder

In this post I see:
- Before jpcidade, CDX is found
- If change filename in IF...ENDIF, bug is moved to another position
- Few time ago I read about some low level functions make directory open for "cache", it's the only thing I can think: cache a wrong directory in multithread
- Alternative folder is "..\" (don't know if this information can help)

Note: this test is running in one thread, but there is the main process running in another thread.

[JoséQuintas]

Vi errado quando olhei o log: jpcadas vém antes de jpcidade e também não achou o índice.
Mas de qualquer forma, alterando o nome do arquivo do IF, altera o início do bug.
Como o path só está dentro da função PathAndFile(), não faz diferença para os outros arquivos.

Então só sobra de suspeito mesmo o File() ou algo relacionado a ele.

É a rotina que uso há mais de uma década.
A única diferença é que vou começar a usar pasta diferente, e acrescentei essa função PathAndFile().
É só o preparativo pra usar pasta diferente, e topei com isso.

isso me lembra um comentário antigo meu: se tem algo com chance mínima de falhar... aqui falha... rs

Obs. Essa UpperFile() criei pra testar File(). Pior que alterei no sistema inteiro, e agora vou ter que desfazer tudo já que não fez diferença.

[JoséQuintas]

Mais um complemento....
Nessa mesma rotina, antes de usar PATH, continuo tendo este problema, que parece estar relacionado:

Error SIXCDX/1006 Create error: jpcadas.cdx (DOS Error 2)
Called from ORDCREATE(0)
Called from ABREIND(97)
Called from ABREARQUIVOS(58)
Called from CHKVERSAO(115)
Called from SISTEMA(132)
Called from (b)MAIN(30)

O cliente onde ocorre este erro é um escritório de contabilidade.
Utiliza várias pastas, uma para cada empresa.
A diferença é que antes de entrar na empresa, pesquiso a lista de nomes disponíveis verificando pastas diferentes.
Ao entrar em uma empresa usa somente a pasta da empresa, que seria o caso quando deu este erro.
Mas parece relacionado.
Detalhe: carrega uma nova instância do EXE apontando pra pasta, e cria os arquivos que não existirem, TODOS no caso de uma empresa nova, que também é justamente quando ocorre o erro. Se recarregar, não tem mais erro.

[Itamar M. Lins Jr.]

Vou coloca aqui a resposta do Przemek, servirá p/ outras pessoas.

Hi,

> Only to complement:
> If I use a invalid filename here, all ok.
>
> FUNCTION PathAndFile( cFileName )
> cFileName := Lower( cFileName )
> SayScroll( "FileName " + cFileName )
> IF cFileName $ "-nofile-nofile-"
> SayScroll( "Entrou no IF" )
> cFileName := AppCommonFolder() + cFileName
> SayScroll( "Novo nome" + cFileName )
> ENDIF
> RETURN cFileName
>
> For me, bug is in File() or in anything that change File() result.
> if name in IF...ENDIF changes one path for File(), File() for
> another path fail.
>
> Try change FIle( cFile ) and use Len( Directory( cFile ) ) and same result.
>
> I am using local, Windows 7 64 bits.

Nothing what you presented so fat suggests that it's Harbour core
problem. Please send such messages to harbour-user list.

> I don't know if this can be related to it.
> This is an old error that I can't solve. Occurs in a small network.
> In same routine, when check CDX and create new one when it does not exists.
>
> Error SIXCDX/1006 Create error: jpcadas.cdx (DOS Error 2)
> Called from ORDCREATE(0)

DOS ERROR 2 - file not found.
OrdCreate() creates and open file in single IO.
If it fails with above error then it's a problem with your network layer.
You have to configure your network and disable oplock and some readahead
buffers. It's also possible that your server wrongly set error to 2 instead
of 3 (path not found) and in such case you have to verify your code and
check directories.
Anyhow if I can see sth in your tests (they are very chaotic) then it looks
like a clasic network configuration problem and directory contents taken
from local network caches is not well synced with server so newly created
files are not visible imeddiatelly. The same happens with just deleted files.
Your network layer see old entires in cached directoy list and reports that
file exists also confusing create operation which probably is internally
switch to open and then server answer with ERROR 2 - file not found.

> Called from ABREIND(97)
> Called from ABREARQUIVOS(58)
> Called from CHKVERSAO(115)
> Called from SISTEMA(132)
> Called from (b)MAIN(30)
>
> Note:
> This client is a account office, and works with several folders.
> After select a folder (or new one), a new instance of EXE is loaded
> to work with that folder and create dbfs/cdxs not found.
> Seems that the directory is locked.
>
>
> Common in the two situations is the use of another folder before
> error. (file(), use, index)
> Or directory is locked, or harbour is locked into another directory,
> or harbour lock the directory ( I don't know if this could be
> possible). (Harbour + Windows)
> Only to remember: my main routine is a hidden window, then
> application uses at least 2 threads.

You are describing situation which look like common problem
with wrongly configured MS-Network clients and/or server.
Please change the news group. In harbour-user archive you will find
reports about problems with MS-network layer and how to configure
oplock/read ahead buffers on client and server side. In Harbour's hbwin
library there are even functions to make such configuration (register
modifications) automatically.
All is in mail archive.

best regards,
Przemek

Saudações,
Itamar M. Lins Jr.