WSL export por filename — retenção de arquivo parcial após falha

[danilorcr]

Estou realizando uma análise documental da exportação nativa de distribuições WSL, nos formatos TAR e VHDX, usando destino por nome de arquivo.

Na release 2.7.13, commit 80697fd, a função ExportDistribution de src/windows/common/WslClient.cpp contém um tratamento de limpeza que solicita DeleteFileW para o arquivo de destino. A liberação desse tratamento, por cleanup.release(), aparece posteriormente no caminho de sucesso.

Referência da release:
https://github.com/microsoft/WSL/releases/tag/2.7.13

Referência do código-fonte:
https://github.com/microsoft/WSL/blob/80697fd42cca3de0c0d5dd1931c36112372a577e/src/windows/common/WslClient.cpp

Esta é uma observação de código-fonte. Não estou relatando uma reprodução no host, exclusão efetivamente concluída ou corrupção de um export bem-sucedido.

Existe alguma implementação oficial já publicada que preserve o arquivo parcial após falha, mantendo as invocações nativas por filename para TAR e VHDX, sem um chamador substituto, redirecionamento do payload para stdout ou dependência de falha incidental da exclusão?

Caso exista, solicito a referência da release, commit e passagem de fonte ou documentação que sustentem essa propriedade. Também seria necessário esclarecer os destinos de payload e diagnósticos nos caminhos pertinentes de sucesso e falha, separadamente para os dois formatos.

Caso não exista uma opção suportada para isso, essa confirmação também é útil. A necessidade é delimitar a capacidade disponível, não presumir uma garantia a partir do código de retorno do export.

[Ramon Santos Pereira (Ramonspe)]

Olá! Não sou da equipe do WSL, mas conferi o código e acho que dá para responder a parte principal: não existe, até a release estável mais recente, uma opção suportada que preserve o arquivo parcial quando o export por nome de arquivo falha.

O que o código faz

Em ExportDistribution() (src/windows/common/WslClient.cpp), o fluxo é o mesmo para TAR (incluindo tar.gz e tar.xz) e para VHD, porque o formato só muda as flags enviadas ao serviço:

1. quando o destino não é -, o arquivo é criado com CreateFileW(..., CREATE_ALWAYS, ...) e compartilhamento FILE_SHARE_READ | FILE_SHARE_DELETE;
2. logo em seguida é registrado um wil::scope_exit_log com o comentário "Delete the target if export was unsuccessful", que chama DeleteFileW no caminho de destino;
3. o payload é escrito pelo serviço no handle desse arquivo (service.ExportDistribution(&distroId, fileHandle, flags));
4. só no fim do caminho de sucesso há o cleanup.release().

Então qualquer exceção entre a criação do arquivo e o release() dispara a exclusão. Como o arquivo foi aberto com FILE_SHARE_DELETE, o DeleteFileW não é bloqueado pelo próprio handle ainda aberto. E se a exclusão falhar por outro motivo, isso só vai para o log (LOG_IF_WIN32_BOOL_FALSE), sem mudar o código de retorno.

A única rota em que nada é apagado é o destino -. Nela o handle é o STD_OUTPUT_HANDLE, o file fica vazio e o lambda de limpeza não faz nada. Mas isso é justamente o redirecionamento para stdout que você excluiu.

Versões conferidas

O trecho de limpeza é o mesmo no commit que você citou (2.7.13), na tag 3.0.3 (última release estável no momento) e no master atual. Entre essas versões o ExportDistribution só mudou na validação de formatos (o tarFormatSet e a checagem com std::popcount), não na limpeza. Também não há flag de linha de comando que desligue esse comportamento: o parser do --export só aceita o nome da distribuição, o destino, --vhd e --format.

Resumindo

Para export por nome de arquivo, em TAR ou VHD, a propriedade que você procura não existe hoje: na falha o destino é apagado por desenho, e o código de retorno diferente de zero é o sinal de que não sobrou artefato. Se preservar o parcial for um requisito, o caminho seria abrir uma issue pedindo uma opção para isso, já que hoje não há como fazer isso sem stdout ou sem um processo intermediário.

Espero que ajude!