OneDrive não é lugar para guardar projeto em desenvolvimento Link para o cabeçalho

Tela de notebook explodindo com fogo, fragmentos do símbolo do OneDrive e arquivos físicos voando em direção ao usuário.

Você cria uma pasta no OneDrive, clona um repositório, instala dependências, abre o editor e começa a trabalhar. Parece uma boa ideia: se tudo está na nuvem, então tudo está protegido.

Até que o terminal fica lento. O editor demora a reagir. O OneDrive passa tempo demais em “processando alterações”.

Depois vêm os avisos mais explícitos: pasta com erro de sincronização, arquivo que não sobe, ícone com círculo vermelho e X branco, ou até mensagens relatadas por usuários como “There are too many files in your OneDrive”. Nesse ponto, aquele “backup automático” já virou mais um processo competindo com o build, o antivírus, o editor, o watcher do framework e a própria linguagem.

O problema não é que OneDrive seja ruim. Ele é muito bom para o que foi feito para fazer: sincronizar documentos, planilhas, PDFs, fotos, arquivos de trabalho e entregáveis relativamente estáveis.

O erro está em tratar uma pasta de projeto ativa como se ela fosse uma pasta de documentos.

Projetos modernos não são apenas “arquivos de código”. Eles são workspaces em execução. O repositório é só a parte estável; ao redor dele, a toolchain cria dependências, caches, binários, índices, ambientes virtuais, arquivos temporários, resultados de build, pacotes baixados, modelos de IA e milhares de pequenos arquivos que mudam o tempo todo. Colocar tudo isso dentro de uma pasta sincronizada em tempo real é pedir para o sincronizador disputar com o próprio ciclo de desenvolvimento.

O problema não é nuvem, é categoria Link para o cabeçalho

Um arquivo Word muda algumas vezes ao longo de uma tarde. Um projeto Node pode criar dezenas de milhares de arquivos ao instalar dependências. Um projeto Python pode montar uma .venv com executáveis, pacotes e caches. Um projeto TypeScript pode gerar dist, .tsbuildinfo e caches de bundler. Um fluxo com Whisper ou outros modelos locais pode baixar pesos grandes, criar cache e processar áudios que não são necessariamente fonte do projeto.

São naturezas diferentes.

O OneDrive olha para o sistema de arquivos e tenta responder a perguntas de sincronização:

esse arquivo mudou?
foi renomeado?
foi apagado?
está aberto?
existe conflito com outra máquina?
esse caminho é permitido?
esse item precisa subir, descer ou esperar?

O ambiente de desenvolvimento, ao mesmo tempo, faz perguntas opostas:

posso apagar e recriar esse diretório de cache?
posso gerar milhares de arquivos pequenos agora?
posso manter esse lock aberto enquanto instalo?
posso observar cada mudança com um watcher?
posso reescrever o output do build a cada salvamento?

Essas duas visões podem coexistir, mas não deveriam disputar o mesmo chão o tempo inteiro.

Onde isso aparece no mundo real Link para o cabeçalho

Node e TypeScript Link para o cabeçalho

O ecossistema Node é o exemplo clássico. A pasta node_modules é famosa por ser grande, profunda e cheia de arquivos pequenos. Mesmo projetos simples podem baixar centenas de pacotes. Em aplicações maiores, entram ainda caches de ferramenta, saídas de build e artefatos de frameworks:

node_modules/
dist/
build/
.next/
.nuxt/
.vite/
.cache/
coverage/
*.tsbuildinfo

Esses itens não são o “produto intelectual” do projeto. Em geral, eles podem ser recriados a partir de package.json, lockfiles e comandos de instalação/build.

O próprio template de .gitignore para Node mantido pelo GitHub lista muitos desses caminhos como itens a ignorar, incluindo node_modules/, caches, outputs de build e arquivos de informação incremental do TypeScript. A documentação do TypeScript também explica que incremental salva informações do grafo do projeto em arquivos .tsbuildinfo no disco.

Isso é ótimo para acelerar builds locais. É péssimo como material de sincronização contínua.

Python Link para o cabeçalho

Python tem o mesmo padrão, com outro vocabulário.

Um ambiente virtual (.venv, venv, env) não é apenas uma configuração: é uma árvore de diretórios com executáveis, scripts, pacotes instalados e site-packages. A documentação do Python descreve o venv como um ambiente próprio, criado sobre uma instalação base, com diretórios específicos para binários e pacotes.

Além disso, Python cria caches e artefatos comuns:

.venv/
venv/
env/
__pycache__/
*.pyc
.pytest_cache/
.mypy_cache/
.ruff_cache/
dist/
build/
site/

Mais uma vez: isso importa localmente, mas não precisa virar sincronização em tempo real. O que deve ser preservado é o código, o pyproject.toml, o requirements.txt, o lockfile quando existir, a documentação e os dados que realmente fazem parte do projeto.

IA local, Whisper e modelos baixados Link para o cabeçalho

Com IA local, a situação fica mais visível porque alguns artefatos deixam de ser apenas numerosos e passam a ser grandes.

O Whisper, por exemplo, é instalado como pacote Python e possui modelos com tamanhos que vão de tiny a large e turbo, com requisitos aproximados de VRAM que a documentação da OpenAI lista entre cerca de 1 GB e 10 GB, dependendo do modelo. A CLI também aceita --model_dir e, quando não informado, usa ~/.cache/whisper como padrão para salvar modelos.

Isso não significa que você nunca possa fazer backup de modelos. Significa que eles não deveriam entrar por acidente na mesma esteira de sincronização dos seus fontes.

Modelo baixado, cache de transcrição, áudio bruto temporário e output intermediário de processamento são coisas diferentes de código-fonte. Misturar tudo em uma pasta sincronizada faz o OneDrive tentar preservar aquilo que muitas vezes é apenas material reconstituível.

Git Link para o cabeçalho

Git merece uma menção separada.

O diretório .git é uma base de dados local. Ele tem objetos, referências, índice, locks e mudanças pequenas frequentes. O Git já é o mecanismo correto para versionar código. OneDrive é outro mecanismo, com outra semântica, tentando observar e sincronizar os arquivos internos desse mecanismo.

Isso não quer dizer que todo repositório dentro do OneDrive vai quebrar. O ponto é mais simples: você está empilhando dois sistemas de estado em cima da mesma pasta. Quando algo fica lento, travado ou conflitante, o diagnóstico fica pior.

O modelo mais saudável é: Git versiona o código; OneDrive, se entrar na história, guarda uma cópia filtrada, um backup, um pacote, um export ou um espelho controlado.

O que o OneDrive reconhece como limite Link para o cabeçalho

A própria Microsoft documenta limitações importantes do OneDrive e SharePoint.

Algumas são especialmente relevantes para desenvolvimento:

para melhor performance, a Microsoft recomenda sincronizar no máximo 300.000 itens no total do armazenamento em nuvem;
problemas de performance podem ocorrer acima desse volume mesmo quando nem todos os itens estão sincronizados;
o caminho decodificado completo, incluindo nome do arquivo, não pode passar de 400 caracteres em OneDrive e SharePoint;
há nomes de arquivos e pastas inválidos ou bloqueados;
arquivos temporários .tmp não são sincronizados;
OneDrive não dá suporte a usar unidade de rede/mapeada como localização de sincronização e não suporta sincronização por links simbólicos ou junction points;
quando há muitos arquivos ou um arquivo grande, o cliente pode passar bastante tempo em “syncing” ou “processing changes”.

Existe também um preview público no Windows para cenários de até 1.000.000 de itens por instância de sync, mas ele tem requisitos específicos de sistema, memória, SSD, processador e cliente Insider. Ou seja: não é uma licença para jogar node_modules, .venv, cache de IA e build de monorepo dentro do OneDrive e chamar isso de arquitetura.

O limite mais importante não é só o número. É a natureza dos arquivos.

Um milhão de PDFs organizados e pouco alterados é uma coisa. Um projeto que cria, apaga e reescreve milhares de arquivos pequenos em ciclos de segundos é outra.

O sintoma clássico: “processando alterações” Link para o cabeçalho

Quando o OneDrive fica em “Processing changes”, a documentação de suporte da Microsoft lista causas como arquivo aberto, muitos arquivos adicionados, arquivo muito grande, login recente ou atualização do computador.

Para usuário comum, isso pode acontecer ao subir uma pasta grande de fotos.

Para desenvolvedor, isso pode acontecer várias vezes no mesmo dia:

npm install;
pnpm install;
pip install;
python -m venv .venv;
pytest;
npm run build;
geração de documentação;
criação de índice de busca;
download de modelo de IA;
transcrição de áudio;
limpeza e recriação de dist.

Cada ferramenta está fazendo algo legítimo. O problema é somar todas elas com sincronização em tempo real.

Quando o problema vira erro visual, a própria documentação da Microsoft descreve o círculo vermelho com X branco como sinal de que um arquivo ou pasta não pode ser sincronizado. E, em discussões de suporte da Microsoft, aparece também o relato direto da mensagem “There are too many files in your OneDrive”. Essa distinção importa: o ícone vermelho é um estado documentado do cliente; a frase exata pode variar conforme idioma, conta, versão do cliente e cenário de sync.

O custo escondido no SSD Link para o cabeçalho

Existe ainda um efeito menos visível: escrita desnecessária no disco.

SSD moderno aguenta muita coisa, então não vale transformar isso em pânico. Mas a vida útil de um SSD não é abstrata. Fabricantes medem resistência em métricas como TBW, de terabytes written, ou DWPD, de drive writes per day. Em termos simples: existe uma quantidade de escrita que o fabricante garante para aquele modelo dentro do período de garantia.

Quando você deixa o OneDrive sincronizar node_modules, .venv, cache de bundler, cache de teste, dist, build e modelos baixados por ferramentas de IA, você cria uma esteira duplicada de I/O. A ferramenta de desenvolvimento escreve. O sincronizador observa, calcula estado, lê metadados, cria fila, sobe, baixa, resolve conflito e pode reescrever arquivo. Em alguns casos, o próprio padrão de escrita pequena e aleatória aumenta o custo interno por causa de mecanismos como garbage collection, wear leveling e write amplification.

Isso não significa que um projeto pequeno no OneDrive vá acabar com seu SSD. O ponto é outro: se dependências, caches e builds são descartáveis, gastar escrita do disco para sincronizá-los é desperdício. Em máquinas com SSD pequeno, mais antigo, muito cheio ou já usado por workloads pesados, esse desperdício deixa de ser apenas teórico.

O modelo que funciona melhor Link para o cabeçalho

Para desenvolvimento local em Windows, eu prefiro separar as responsabilidades:

C:\Dev\
  projeto-a\
  projeto-b\
  projeto-c\

OneDrive\
  Backups\
  Entregaveis\
  Documentos\

O código ativo fica fora do OneDrive. Pode ser C:\Dev, um Dev Drive no Windows 11, ou outro volume local rápido. O repositório remoto fica no GitHub, GitLab, Azure DevOps, Bitbucket ou servidor Git privado. O OneDrive entra como backup filtrado, não como fonte viva.

Esse desenho tem uma vantagem meio sem graça e muito valiosa: cada ferramenta faz aquilo que sabe fazer.

Git cuida de histórico, branch, diff, merge e colaboração.
O disco local cuida de I/O rápido para build e dependências.
O OneDrive cuida de documentos, entregáveis e backup.
O rclone faz uma ponte controlada quando você quer espelhar parte do ambiente.

E o Dev Drive? Link para o cabeçalho

No Windows 11, Dev Drive é uma alternativa interessante para workloads de desenvolvimento. A documentação da Microsoft descreve Dev Drive como um volume pensado para melhorar performance em cargas de trabalho de desenvolvedor, usando ReFS e integração com o modo de performance do Microsoft Defender.

Isso não substitui Git e não substitui backup. Ele resolve outra parte do problema: reduzir atrito local para arquivos de projeto, builds e dependências.

Uma configuração razoável pode ser:

D:\Dev\                 # Dev Drive ou volume local rápido
  meu-projeto\

OneDrive\DevMirror\     # espelho filtrado, não workspace ativo

Se você não usa Windows 11 ou não quer criar Dev Drive, C:\Dev já melhora bastante simplesmente por sair da pasta sincronizada.

Onde o rclone entra Link para o cabeçalho

rclone é uma ferramenta de cópia e sincronização entre sistemas de arquivos e serviços de nuvem. Para OneDrive, ele tem backend próprio, autenticação via Microsoft, suporte a hashes, listagem e opções específicas.

A parte mais importante, neste contexto, é filtro.

Em vez de mandar a árvore inteira do projeto para o OneDrive, você define o que fica fora:

- **/node_modules/**
- **/.pnpm-store/**
- **/.venv/**
- **/venv/**
- **/env/**
- **/__pycache__/**
- **/.pytest_cache/**
- **/.mypy_cache/**
- **/.ruff_cache/**
- **/.cache/**
- **/.next/**
- **/.nuxt/**
- **/.vite/**
- **/dist/**
- **/build/**
- **/coverage/**
- **/public/**
- **/resources/_gen/**
- **/.git/**
- **/*.tsbuildinfo
- **/*.pyc
+ **

Isso é um exemplo, não uma lei universal. Cada projeto tem seus próprios diretórios importantes e descartáveis.

O comando deve começar em modo simulado:

rclone sync "C:\Dev" "onedrive:DevMirror" `
  --filter-from "C:\Dev\.sync\rclone-dev.filter" `
  --dry-run `
  --progress `
  --stats 10s

O exemplo completo do wrapper PowerShell e do filtro de rclone usado nesse desenho está no repositório de exemplos do blog: onedrive-projetos-desenvolvimento-rclone .

Só depois de revisar o que seria copiado e o que seria ignorado faz sentido remover o --dry-run.

Também vale pensar se você quer sync ou copy:

copy copia sem apagar no destino o que sumiu na origem;
sync faz o destino espelhar a origem, incluindo remoções;
--delete-excluded deve ser tratado com muito cuidado, porque manda apagar no destino arquivos que agora batem nos filtros excluídos.

A documentação do rclone é bem direta nesse ponto: filtros são poderosos, mas ordem, raiz relativa e ** importam. Antes de confiar, use --dry-run, -v e, quando necessário, --dump filters.

O que sincronizar Link para o cabeçalho

Uma regra prática:

Sincronize o que você escreveu, configurou ou recebeu como insumo real.

Exemplos:

src/
docs/
content/
scripts/
tests/
README.md
package.json
package-lock.json
pnpm-lock.yaml
pyproject.toml
requirements.txt
uv.lock
poetry.lock
.env.example

Não sincronize aquilo que a máquina recria.

Exemplos:

node_modules/
.venv/
__pycache__/
.pytest_cache/
.mypy_cache/
.ruff_cache/
.next/
.vite/
dist/
build/
coverage/
.git/
*.tsbuildinfo

Existe exceção? Claro. Um projeto pode ter um dist que é entrega final para um cliente, ou um build que contém um pacote assinado, ou um modelo local que você não consegue baixar de novo com facilidade. Mas exceção precisa ser consciente. Se tudo é exceção, o filtro não existe.

O que eu faria na prática Link para o cabeçalho

Para uma máquina Windows de desenvolvimento, meu fluxo recomendado é:

Criar uma raiz local para código, como C:\Dev.
Clonar repositórios ali, fora do OneDrive.
Usar Git remoto como fonte de verdade do código.
Manter .gitignore bem cuidado.
Usar OneDrive para documentos, entregáveis e backups filtrados.
Criar um filtro de rclone para excluir dependências, caches, builds e .git.
Rodar rclone primeiro com --dry-run.
Automatizar o espelho apenas depois que o relatório estiver limpo.
Separar pastas de dados grandes, modelos e mídia bruta por intenção: fonte, cache, entrega ou temporário.

Isso não é tão mágico quanto “joga tudo no OneDrive”. Mas é muito mais previsível.

Checklist rápido Link para o cabeçalho

Antes de colocar um projeto dentro de qualquer sincronizador em tempo real, pergunte:

Essa pasta tem node_modules?
Tem .venv?
Tem .git?
Tem build incremental?
Tem cache de bundler?
Tem modelos de IA?
Tem áudio, vídeo ou dataset bruto?
Tem milhares de arquivos pequenos?
Tem caminhos profundos?
Tem arquivos sendo reescritos por watchers?
Tem cache ou build gerando escrita constante no SSD?

Se a resposta para duas ou três dessas perguntas for “sim”, o melhor lugar para desenvolvimento ativo provavelmente não é o OneDrive.

Use OneDrive como cofre, não como bancada.

Na bancada ficam as ferramentas em uso, sujeira temporária, serragem e tentativa. No cofre fica o que precisa ser preservado.

Código-fonte vive muito bem com Git. Dependências vivem muito bem sendo reinstaladas. Cache vive muito bem sendo apagado. Backup vive melhor quando é intencional.

O trabalho do desenvolvedor fica mais leve quando essas fronteiras ficam claras.