Clone and Rehydrate may overwrite blobs when destination checks fail

Abierto
#9,233 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
22/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
azure

Línea de trabajo

Start in the Clone and Rehydrate flow, tracing how the destination-blob existence checks, the container check and the subsequent copy are sequenced, and how a failed blob check is interpreted as a missing destination. The payload names no specific files or tests, so locate them from those function names. Done means a reproduction with injected check failures, plus either a blocked Apply or an explicit overwrite confirmation, and the maintainers have agreed on the intended behaviour.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

Source inspection identified a potential data-loss risk in Clone and Rehydrate. If the destination-existence checks both fail, the operation may treat an existing blob as absent and overwrite it. This has not been reproduced, and no data loss has been verified.

Conditions to investigate
  • The destination container exists and its initial container check succeeds.
  • A blob with the selected destination name already exists.
  • Both the destination-blob property check and the listing check fail, for example because of transient errors or permissions that allow the container check and copy but prevent blob reads and listing.
  • A subsequent copy request succeeds.
Proposed reproduction (not yet run)

Use disposable test data, not a production account.

  1. Create an archived source blob and an existing destination blob.
  2. Arrange for both destination-blob existence checks to fail while allowing the initial container check and the subsequent copy to succeed. The exact permission configuration or failure injection still needs to be established.
  3. Open Clone and Rehydrate, enter the existing destination name, and observe whether Apply is enabled and whether the existing blob is overwritten.
Expected experience

If the destination cannot be checked, the operation should report the failure and avoid silently overwriting an existing blob.

Actual experience

Not observed. Source inspection suggests that failures of both blob-existence checks can be treated as a missing destination, enabling Apply, and that the subsequent copy has no overwrite condition or separate confirmation. In contrast, a failed container-existence check prevents Apply, although its message may say the container does not exist.

Environment and related report

Storage Explorer version, build, operating system, architecture, authentication method, and an exact reproducing permission setup have not been verified. A previous same-name warning report is closed; it did not describe failures of both existence checks.

Lenguaje dominante
Sin datos de lenguaje
Estrellas
458
Forks
92
Merge medio
17 h 57 min
PR fusionados (30 d)
4

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/AzureStorageExplorer

Todos los issues de microsoft/AzureStorageExplorer

Issues similares

Más issues de Cloud

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.