Tudo bem deixar um pequeno script de loop infinito rodando no servidor? [fechadas]

Question

Parece que preciso atualizar o cenário completo para todos.

Nossos usuários precisam pegar o que precisarem do nosso servidor de arquivos para sincronizar com o local remoto, mas os usuários têm permissões limitadas no servidor de arquivos para mover arquivos. então aqui está minha tarefa:

create a tool that user can use to pickup data and sync to remote location. DFS and 3rd party tools are not options, must be codes made by our own and everything must be running on background.

Aqui está a minha maneira de fazer isso e está funcionando agora. Eu fiz 3 peças de componentes:

** Um aplicativo **** HTA com VBS localizado no PC do usuário, fornecendo ao usuário um navegador de arquivos para coletar dados.

** B **** Um local compartilhado que permite que o HTA grave o caminho de dados em um arquivo txt. qualquer caminho neste arquivo de texto será feito como um link para um local final.

** C **** Um local final no servidor de arquivos contém todos os softlinks.

Veja como basicamente funciona:

O usuário seleciona um dado do servidor de arquivos usando o HTA que eu criei. Ele gravará o caminho completo dos dados para o arquivo 000.txt no local compartilhado. Meu script de loop infinito monitora esse local compartilhado, se o arquivo 000.txt for criado por qualquer usuário nesta pasta compartilhada, ele chamará outro script para ler todos os caminhos de dados neste 000.txt e usar mklink para criar softlinks com base em os caminhos fornecidos pelo usuário e saídas de softlinks para o local final e, em seguida, exclui o arquivo 000.txt. Todos os softlinks neste local final serão sincronizados por robocopy durante a noite no horário. Existem mais funções necessárias no meu aplicativo HTA, não há necessidade de falar sobre isso.

Como ninguém aqui falando sobre codificação, excluí meu código de loop infinito. Esse script de loop começa com o Windows e é executado como um serviço. Eu posso começar / parar quando quiser. Basicamente, apenas monitora essa pasta compartilhada, se algum usuário criar o arquivo 000.txt lá, ele chamará mklink.bat para fazer as softlins e o arquivo 000.txt será excluído por mklink.bat quando a conexão for feita. O motivo pelo qual eu uso um loop infinito em vez de um agendador de tarefas é que o usuário precisa ver os resultados nesse local final logo após enviar o caminho de dados. Eu pensei que o intervalo mínimo de agendador de tarefas é um min, (@MikeAWood disse que pode ser 1 segundo. Obrigado!) Então eu fiz um loop infinito de intervalo de 2 segundos para monitorar essa pasta compartilhada.

Minha pergunta foi a seguinte:

Is this a good idea to running a endless loop on server like forever to monitor a folder?

I monitored the resources usage on server while this script is running. I dont see any significant consumings...so I guess it will be harmless right?

Se o agendador de tarefas puder lidar com intervalos de 1 segundo, acho que minha pergunta está resolvida. Obrigado a todos vocês.

Ou se você tem uma maneira melhor de fazer isso ou qualquer opinião sobre o jeito que eu faço.

    

Answer 1

Como alternativa geral a isso: coloque seu script no Agendador de Tarefas e acione-o a cada minuto, dois minutos, o que for. Isso é mais confiável, pois seu processo com sobreviver reinicia ou erros de script. O uso de Tarefas agendadas não apenas permite que o processo sobreviva a reinicializações, como já foi mencionado, mas também pode torne sua tarefa implantável em um grande número de servidores por meio das Preferências de Política de Grupo. Sua solução atual é inimiga da escalabilidade e confiabilidade.

Quanto ao script que você está falando - parece que você está reinventando o Frankenstein's Monster of DFS-R e / ou Robocopy.

O DFS-R é uma ferramenta de replicação de arquivos madura e escalonável que é incorporada ao Windows Servidor. Você deve ver se você pode usá-lo para esta situação. A Microsoft colocou muito mais poder intelectual no DFS-R do que você poderia usar em um script que faz a mesma coisa.

Além disso, mesmo que você não consiga usar o DFS-R por algum motivo, robocopy tem um /mir switch, que irá espelhar os diretórios. Se você realmente não pode usar o DFS-R por algum motivo, pelo menos use algo assim em um script.

    

Answer 2

Você deve ser elogiado por perguntar sobre sua abordagem. É fácil de executar com a primeira ideia que você tem, mas é melhor validar com os outros.

Vários problemas com sua abordagem:

• Tem que ser reiniciado manualmente sempre que o servidor reiniciar
• Requer que você permaneça conectado ao console com credenciais que tenham acesso à origem & destino
• Já existem ferramentas que fazem isso (DFS, tarefas agendadas, etc.)

(Alguns desses problemas podem ser abordados como você mencionou no serviço.) Dito isso, somente você pode avaliar a validade de qualquer solução específica para o problema que enfrenta. Pelo menos agora você tem opções.

    

Answer 3

Certamente, existem maneiras melhores de fazer isso do que executar um loop infinito. Loops sem fim são dor e causam frustração em todos os níveis para todos. Por favor, não faça isso.

    

Answer 4

Estou curioso por que você está perguntando. Várias pessoas ofereceram soluções alternativas e a resposta parece ser que você recebeu ordens para fazer isso dessa maneira. Você está procurando alternativas ou está procurando munição para voltar ao seu gerente e protestar dessa maneira?

As razões para não fazê-lo desta maneira foram enumeradas em outras respostas:

• é propenso a falhas, pois não sobreviverá a uma falha ou a um reinício do sistema ou a qualquer tipo de erro de processamento.

• requer esforço de sua parte (em oposição ao de um fornecedor) para manter

• existem riscos de segurança para este método

• é relativamente ineficiente

Com relação às alternativas, eu também tive uma experiência ruim com o DFS e usei o DoubleTake Replication com ótimos resultados. No entanto, uma versão subsequente do DFS resolveu meus problemas com o DFS e agora usamos isso para a replicação DR em uma WAN.