PC Toledo

Toda vez que eu crio uma tabela temporária em memória aparece um arquivo mem sem extensão com tamanho 0
Tem como inibir a criação deste arquivo? o problema é se o executável estiver rodando em pasta de rede com atributo somente leitura o que acontece?
O harbour se vira ?

e so vc criar o arquivo mem em pasta local
DbCreate("c:\temp\mem:etiquetas", aStru,, .T., "ETIQUETAS")

Valeu Daniel,

Funcionou.

Eu sei que eu poderia até incluir a hbmemio.hbc e fazer o request hb_hbmemio mas eu não sabia do truque caminho antes de ":mem"

:)Pos

A diferença quando não se usa o hb_memio é que a função cria um arquivo temporário para processar.

Olá!

Aqui, usando Hb_MemIo, o código original não criou o arquivo em disco. Para compilar: HBMK2 MEMTEST hbmemio.hbc -b

Tentei sua solução, alxsts, mas não consegui compilar. Depois de incluir a chamada ao HB_MEMIO no começo, nos requests o Harbour diz que:

.hbmk/win/mingw/sudoku.o:sudoku.c:(.data+0x4c8): undefined reference to `HB_FUN_HB_MEMIO'
collect2: ld returned 1 exit status

Verifiquei e realmente não há, na minha versão, o arquivo "HB_MEMIO". Mas há os seguintes arquivos com nomes parecidos, ambos na pasta "C:\hb32\lib\win\mingw":

"libhbmemio.a"
"libhbmemio.dll.a"

Já na pasta "C:\h32\contrib\hbmemio" há:

"hbmemio.hbc"
"hbmemio.hbx"

e em "C:\hb32\bin" há hbmemio-32.dll.

O fato é que o arquivo "mem", com zero bytes, continua lá...

Gozado é que os outros requests que faço,

REQUEST HB_LANG_PT
REQUEST HB_CODEPAGE_PT850

...bem, não há nenhum arquivo com esses nomes sob "C:\hb32", mas as funções estão uma beleza: por exemplo, o que escrevo e leio com memoedit() está certinho.

Também estranho o número de parâmetros para dbcreate(). É como foi, para mim, iniciante, uma descoberta saber que a inkey() no Harbour aceita mais de um parâmetro, além do tempo de aguardo... Saberia dizer onde há algum manual ou referência a essa - e outras - funções?

Asimões:

Seguinte:
Existe um recurso no Windows, aonde cria essa pasta de tamanho zero.
Não se vê o que tem dentro, não se pode copiar, etc. etc.
Pode ser acessado somente se souber o nome.
Se não souber o que tem dentro, não se acessa.

Na época que descobri isso, criava fácil com o bloco de notas, apenas indicando os dois pontos.
Mas não anotei, e nunca mais consegui.
Não sei se é a mesma coisa.
De repente depende do SO, por isso, se possível, gostaria de detalhes.

Cheguei até a rodar o aplicativo desse jeito, ficava totalmente protegido, mas foi só curiosidade na época.

O que estou fazendo, caro José Quintas, é apagar esse arquivo na saida do programa:

DELETE FILE MEM.

E quando o programa é carregado de novo, ele recria esse "mem" vazio...

Se a gente não o apaga, chama o programa com o "mem" lá, não tem nenhum problema: o .DBF é criado normalmente na RAM e funciona bonitinho. No meu caso fiquei foi curioso mesmo... mesmo fazendo como estou:
se não fosse pelo DELETE FILE, o "mem" continuaria ali...

Agora, criar arquivo com zero bytes, não sei se entendi sua questão, é fácil: clique direito no diretório , "Criar", "Novo", "Arquivo de Texto" e ENTER.

É que não consigo recriar a situação.

Algo como salvar no bloco de notas com o nome "mem:arquivo.txt"

No diretório aparecia o arquivo MEM com tamanho zero.

copy mem:arquivo.txt lixo.txt não funcionava

Mas abrindo novamente no bloco de notas mem:arquivo.txt, lá estava o arquivo.

Lembro na época que era um recurso do NT, algo relativo a "stream file", mas nunca mais consegui repetir a operação.
Como não anotei, e por não funcionar mais, já não sei se era desse jeito mesmo.
Lembro que estava relacionado a quando fiz o teste desse arquivo de memória no Harbour.

Acabava funcionando como um diretório escondido/protegido.
Tão protegido que nem dava pra fazer backup.... rs

Achei:

The NTFS file system provides applications the ability to create alternate data streams of information. By default, all data is stored in a file's main unnamed data stream, but by using the syntax 'file:stream', you are able to read and write to alternates. Not all applications are written to access alternate streams, but you can demonstrate streams very simply. First, change to a directory on a NTFS drive from within a command prompt. Next, type 'echo hello > test:stream'. You've just created a stream named 'stream' that is associated with the file 'test'. Note that when you look at the size of test it is reported as 0, and the file looks empty when opened in any text editor. To see your stream enter 'more < test:stream' (the type command doesn't accept stream syntax so you have to use more).

NT does not come with any tools that let you see which NTFS files have streams associated with them, so I've written one myself. Streams will examine the files and directories (note that directories can also have alternate data streams) you specify and inform you of the name and sizes of any named streams it encounters within those files. Streams makes use of an undocumented native function for retrieving file stream information.

Foi isso que usei uma vez e nunca mais consegui repetir.
No Windows os dois pontos no nome do arquivo tinha um uso especial, e esse recurso do Harbour acabava se misturando a esse recurso, o que não deveria.

Aqui até mais detalhado:

http://www.flexhex.com/docs/articles/al ... eams.phtml

Sobre o tópico:
Ao que parece, ao invés do arquivo em memória do Harbour, está sendo criado esse "alternate data stream" do NTFS.

Resumindo:
Mostra um arquivo de tamanho zero, mas na prática é como um diretório, que pode estar cheio de coisas dentro.
Com certeza isso não é a intenção do Harbour, porque seria arquivo em disco, e não em memória.
Trata-se de algum tipo de conflito entre a função do Harbour e esse tipo de arquivo, que não sei dizer aonde acontece.

Antes o bloco de notas aceitava, agora não aceita mais.
Acabo de fazer um teste com 2 arquivos, mais do que tem nesse link que indiquei, e obtive o resultado que eu tinha obtido antes.
Acompanhem:

d:\temp>echo texto numero 1 > text:texto1

d:\temp>echo texto numero 2 > text:texto2

d:\temp>dir text.*
O volume na unidade D é TRABALHO
O Número de Série do Volume é 6C40-6731

Pasta de d:\temp

14/02/2016 21:52 0 text
1 arquivo(s) 0 bytes
0 pasta(s) 194.472.779.776 bytes disponíveis

d:\temp>more < text:texto1
texto numero 1

d:\temp>more < text:texto2
texto numero 2

Dentro de text, indicado como tamanho zero, tem os dois arquivos texto1 e texto2

E o mesmo efeito ocorre se usar mem:cliente.dbf
Portanto, se acontecer isso no disco, não é arquivo em memória, e sim em disco.
Terão que testar em Windows diferentes, pra ver o que acontece com cada um.
Com certeza da outra vez usei o bloco de notas, onde agora não funciona mais.

Desculpem por tanto post, mas é algo muito interessante, e pelo jeito causa algum bug no recurso do Harbour.
Se no seu Windows acontece isso, não é arquivo em memória, e precisaria relatar o bug.

Só complementando usando o mem:

d:\temp>echo ksdjkjdjfs > mem:texto1

d:\temp>dir
O volume na unidade D é TRABALHO
O Número de Série do Volume é 6C40-6731

Pasta de d:\temp

14/02/2016 21:57 <DIR> .
14/02/2016 21:57 <DIR> ..
14/02/2016 21:57 0 mem

d:\temp>echo ksdjfkjkdjfdsd > mem:texto2.txt

d:\temp>dir
O volume na unidade D é TRABALHO
O Número de Série do Volume é 6C40-6731

Pasta de d:\temp

14/02/2016 21:57 <DIR> .
14/02/2016 21:57 <DIR> ..
14/02/2016 22:00 0 mem

d:\temp>more < mem:texto1
ksdjkjdjfs

d:\temp>more < mem:texto2.txt
ksdjfkjkdjfdsd

d:\temp>more < mem:x
O sistema não pode encontrar o arquivo especificado.

Interessante!

Faz uns meses meu filho baixou um arquivo compactado da Internet com um logo do qual ele precisava. E nesse arquivo - um .rar - vinham versões para MAC e para PC. Nós descompactamos esse arquivo e ele criou uns arquivos que a gente não conseguia deletar do HD e que tornavam inviável, pelos seus tamanhos, copiá-los para um pen drive.

Xeretando descobrimos que uma parte do nome desses arquivos era constituida de ":"! Sei lá... no meio do arquivo... algo como "hammer:symbol.jpg". Acabamos descobrindo que esses arquivos eram os tais de "streams", só conseguimos deletá-los com a ajuda de um utilitário que enxerga justamente esse tipo de arquivo, "stream", o "AlternateStreamView" da NirSoft. Esse programa deu uma varrida no HD e descobrimos muitos, muitos outros arquivos desse tipo, que a turma chama de "ADS" espalhados por todo lugar. Tenho uns filmes antigos aqui, que baixo via torrent... praticamente todos eles tinham um ADS anexo, "Zone Identifier"... tentei "matar" todos eles, a maioria foi para o espaço mesmo. Os relacionados aos filmes, foram todos. Mas havia uns que o programa não deletou, deu como justificativa que o SO não deixava. Deviam estar sendo usados pelo Windows...

Esses arquivos aparentavam estar vazios mas ocupavam exatamente um cluster na NTFS comum: 4096 bytes... Outros, os que aparentemente tinham alguma informação (lembro do tal "hammer", que era uma imagem), eram enormes... Em tempos de HDs de terabytes, parece mesquinharia se importar com 4k. Mas caro Quintas, 4K já foi algo muito importante,rs...

Mas voltando à vaca fria, fiz daquele jeito mesmo, "DELETE FILE", deselegante e truculento. Valeu para aprender...

Abração!

Mas não tem limite.
4K é o tamanho mínimo que foi considerado pra 0 bytes.
Dentro dele pode ter um HD inteiro, e vai continuar mostrando tamanho 0, e ocupando 4k.

Dá até pra castigar alguém, criando um arquivo de tamanho zero que lota o HD.... rs

Mas pense bem: se está acontecendo isso com Harbour no seu Windows, significa que não foi criado na memória, e sim no HD.