Isso provavelmente não é um comportamento que você pode alcançar facilmente, mas pode haver um truque.
Quando um arquivo é aberto para gravação e os dados são gravados nele, eventualmente, o bloqueio de gravação no arquivo é liberado. No momento, os metadados do arquivo, como Data de modificação, são atualizados.
Quando arquivos são criados, excluídos, renomeados ou alterações são salvos neles, um evento do SO é disparado, detalhando o tipo de alteração e o diretório afetado. Programas como o Dropbox Sync estabelecem "observadores" em certos diretórios para que eles sejam notificados quando algo mudar. Sync percebe a mudança e inicia sua rotina. Uma alteração de tamanho não seria detectada, porque o volume é de tamanho estático. O importante é que somente quando uma alteração de arquivo é concluída, ele dispara um evento de diretório que a sincronização notará.
Quando você monta um volume Truecrypt, um bloqueio de leitura / gravação é estabelecido no volume , a menos que seja montado como somente leitura. Esse bloqueio permanece até que o arquivo de volume seja desmontado. Uma vez que o volume é montado, seu PC pode acessar um arquivo no volume, usando o sistema de arquivos do próprio volume, e abri-lo para gravação. Quando esse arquivo é salvo ou fechado, os metadados são atualizados e um evento de diretório é disparado, mas indica o arquivo que foi alterado por seu local montado (por exemplo, z: \ MyFiles \ File1.doc). O Dropbox nunca ouviu falar desse diretório antes e não está atento a alterações nele. No entanto, o bloqueio de gravação no próprio arquivo de volume não foi liberado, porque o volume ainda está montado para acesso de gravação e seus metadados não foram alterados.
Observe que, mesmo que a sincronização tenha observado alterações em z: \ MyFiles \ (o local montado de um arquivo no volume), ele descriptografaria o arquivo e o armazenaria em texto sem formatação no Dropbox.
No seu caso, você está atualizando o sistema de arquivos dentro do seu volume TrueCrypt, e os dados estão sendo gravados no blob binário dentro do seu arquivo de volume. Isso altera o estado do arquivo, mas faz isso de maneira que não dispare um evento de diretório. somente quando o arquivo é desmontado, o bloqueio de gravação é liberado e um evento de diretório disparado.
Depois de analisar o problema, tenho uma teoria de que você pode contornar o problema criando ou editando um arquivo dentro da pasta sincronizada. Eu não tenho idéia se vai funcionar, e é um hack sujo, então use a seu próprio critério.
Este thread indica que o Dropbox Sync usa rsync e rdiff para realizar a diferenciação na pasta, e pode atualizar os blobs binários no lugar, sem substituir o arquivo inteiro. Isso significa que, em teoria, se um evento do Directory foi acionado enquanto o volume foi montado, as alterações, desde a montagem, seriam carregadas.
No entanto, essa abordagem é perigosa porque um salvamento incompleto pode estar em andamento e pode resultar na sincronização de dados truncados ou corrompidos. O cache de gravação de disco no volume interno pode dificultar a determinação de quando os dados foram completamente liberados para o disco. Isso é parte do motivo pelo qual esperar por desmontar é uma boa ideia, já que desmontar libera o cache de gravação imediatamente. Mesmo se o cache de discos estiver desabilitado, ainda há o perigo de que o sistema de arquivos interno não esteja em um estado de repouso estável na instância em que a diferença é calculada, o que poderia corromper seu volume no final da caixa de depósito.