Cómo eliminar los metadatos en Google Drive: guía completa y casos especiales

Portada » La Nube » Cómo eliminar los metadatos en Google Drive: guía completa y casos especiales

Eliminar metadatos en Google Drive

Si te preocupa qué información extra viaja con tus archivos en la nube, seguramente te hayas preguntado cómo limpiar o controlar esos datos invisibles. En Google Drive, los metadatos abarcan desde etiquetas y texto indexable hasta miniaturas y propiedades del archivo. La clave es entender qué se puede quitar, qué solo se puede actualizar y qué no se puede tocar, para actuar con precisión sin romper nada.

A lo largo de esta guía reunimos, en un único sitio, lo que está disperso por varias documentaciones oficiales y artículos de ayuda de Google. Verás cómo eliminar metadatos de etiquetas en un archivo, gestionar el texto indexable y las miniaturas, y conocerás límites y excepciones. Además, aclaramos escenarios cercanos (transferencias en Cloud Storage y metadatos de VMs en Compute Engine) para que no haya confusiones si trabajas con Google Cloud.

Qué son los metadatos en Drive y hasta dónde llega el término

En Google Drive, los metadatos incluyen información como nombre, tipo MIME, extensión inferida, etiquetas (labels), texto indexable y miniaturas asociadas. Algunas piezas son editables o eliminables (por ejemplo, etiquetas), otras se actualizan indirectamente (texto indexable y miniaturas) y otras no se pueden borrar porque forman parte del sistema (como el tamaño del archivo o fechas internas de creación y actualización).

También verás referencias a metadatos en otros productos de Google Cloud, como Cloud Storage o Compute Engine. No debes confundir los metadatos de una VM o de un objeto en Cloud Storage con los de un archivo de Drive; comparten el concepto, pero su gestión y límites son distintos.
Gestionar metadatos en Drive

Qué se puede quitar realmente en Drive

Desde el punto de vista práctico, lo que más se considera «eliminar metadatos» en Drive es quitar etiquetas (labels) aplicadas a un archivo. Las etiquetas pueden contener campos (texto, usuario, etc.) y eliminarlas suprime su información asociada en ese archivo. Este borrado se realiza por API con operaciones atómicas.

El texto indexable (contentHints.indexableText) no se «elimina» como tal con un botón; se sobreescribe o se deja vacío cuando actualizas el recurso del archivo. Es un contenido pensado para mejorar la detectabilidad de tipos de archivo que Drive no indexa de forma nativa.

Las miniaturas personalizadas se gestionan de forma similar: puedes subir otra imagen de miniatura o dejar de proporcionarla. Si Drive puede generar una miniatura estándar, usará la suya; si no puede, usará la que proporciones.

Hay metadatos que no se pueden borrar en Drive, como el tamaño del archivo o las marcas de tiempo internas. Estas propiedades del sistema se actualizan por el propio servicio y no admiten eliminación directa.

Eliminar etiquetas (labels) de un archivo en Google Drive

La API de Drive permite modificar o quitar etiquetas mediante el método files.modifyLabels. La petición incluye un objeto de tipo ModifyLabelsRequest con una o varias modificaciones que se aplican de forma atómica (si alguna no es válida, no se aplica nada).

Para eliminar por completo una etiqueta de un archivo, se envía una LabelModification con el identificador de la etiqueta y la instrucción de borrado. Este proceso elimina todos los campos de esa etiqueta en el archivo. Si solo necesitas desactivar un campo concreto, puedes «desestablecer» ese campo sin quitar la etiqueta completa.

Pasos conceptuales para quitar una etiqueta en un archivo concreto: 1) identifica el labelId de la etiqueta presente en el archivo (puedes listarlas con files.listLabels), 2) envía la modificación con removeLabel activado, 3) valida que la respuesta incluya el estado final de las etiquetas actualizadas.

Texto indexable: control, límites y buenas prácticas

Si tu aplicación guarda tipos de archivo que Drive no indexa solo (dibujos, vídeos, accesos directos, etc.), puedes aumentar la capacidad de búsqueda rellenando contentHints.indexableText. Este texto se procesa como HTML, se indexa y puede aparecer en resúmenes de resultados en más superficies de búsqueda.

Recomendaciones y límites importantes: el tamaño máximo de indexableText es de 128 KB; captura términos y conceptos que realmente describan el contenido; no intentes ordenar el texto por relevancia, el indexador ya prioriza; actualiza el texto en cada guardado; evita «relleno» de palabras clave no relacionadas (acaba frustrando a los usuarios y puede incentivar borrados).

Ten presente que, al tratarse como HTML, se indexa el contenido textual y no atributos. Por ejemplo, si tu cadena incluye etiquetas con atributos, se indexará el texto visible, no los valores de esos atributos.

Miniaturas: subir, reemplazar y recuperar

Drive genera miniaturas automáticamente para Documentos, Hojas y Presentaciones, entre otros tipos. Si tu tipo de archivo no genera miniatura estándar, puedes proporcionar una configurando contentHints.thumbnail al crear o actualizar el archivo.

Requisitos para miniaturas personalizadas: usa PNG, GIF o JPG; ancho recomendado 1600 px (mínimo 220 px); tamaño máximo del archivo 2 MB; aporta la imagen codificada en base64 segura para URL y el mimeType correcto. La miniatura debe actualizarse en cada guardado, porque se invalida cuando cambia el contenido del archivo (cambios solo de metadatos no la invalidan).

Para recuperar la miniatura, consulta el campo thumbnailLink del recurso files. Es un enlace de corta duración y solo aparece si tu aplicación puede acceder al contenido. Si el archivo no es público, necesitarás credenciales al usar ese link.

Ejemplos de consulta de metadatos con miniaturas por REST:

GET https://www.googleapis.com/drive/v3/files/FILE_ID?fields=id,name,mimeType,thumbnailLink
GET https://www.googleapis.com/drive/v3/files?q=mimeType='application/vnd.google-apps.spreadsheet'&fields=files(id,name,mimeType,thumbnailLink)

Nombres y extensiones de archivo: lo que conviene saber

Al insertar un archivo por API, se recomienda especificar la extensión en la propiedad name (por ejemplo, cat.jpg). Drive propagará esa extensión como fileExtension de solo lectura en respuestas posteriores, y cuando el usuario descargue el archivo o se sincronice al cliente de escritorio, se generará el nombre completo basado en el título.

Si no proporcionas extensión, Drive intentará determinarla a partir del tipo MIME. Siempre que puedas, especifícala para evitar sorpresas.

No confundas quitar metadatos con borrar archivos

Eliminar metadatos y eliminar archivos son acciones distintas. Si eres el propietario de un archivo y lo mandas a la papelera, no estás limpiando metadatos: estás quitando el archivo de tu unidad. La opción de quitar (cuando no eres el dueño) simplemente lo saca de tu vista, pero otros aún lo verán.

Enviar un archivo a la papelera en la web: entra en drive.google.com, clic derecho y selecciona Mover a la papelera. Si otra persona es la propietaria, verás Quitar. Para borrar de forma definitiva, vacía la papelera. Ninguno de estos pasos «borra metadatos» del archivo conservado: o eliminas el archivo o gestionas sus metadatos mediante las opciones explicadas.

Transferencias y conservación de metadatos en Cloud Storage (por si mueves datos)

Cuando trabajas con el Servicio de transferencia de almacenamiento hacia/desde Cloud Storage, hay reglas sobre qué metadatos se conservan y cuáles no. Esto es clave si usas Drive junto a buckets o migras datos entre nubes.

De Amazon S3 o compatibles a Cloud Storage

• Se conservan campos de metadatos de clave fija (p. ej., Cache-Control, Content-Disposition, Content-Type).
• Los metadatos definidos por el usuario pasan a metadatos personalizados en Cloud Storage (editables).
• El ETag se guarda como personalizado con la clave x-goog-source-etag.
• Tamaño del objeto se conserva como size.
• Listas de control de acceso y etiquetas de objeto de S3: no se conservan.
• Metadatos de marcas de tiempo de S3: no se conservan. En Cloud Storage, timeCreated y updated reflejan el momento de creación/actualización en destino.
• Clase de almacenamiento: configurable durante la transferencia (por defecto, la del bucket destino).

De Microsoft Azure Blob a Cloud Storage

• Campos de metadatos de clave fija: se conservan.
• Metadatos definidos por el usuario: se guardan como personalizados en Cloud Storage.
• ETag se conserva como x-goog-source-etag.
• Tamaño como size. Permisos POSIX de ADLS Gen2 y control de acceso específicos: no se conservan.
• Metadatos de marca de tiempo de Azure: no se conservan. timeCreated/updated se recalculan en destino.
• Clase de almacenamiento: configurable como en el caso de S3.

Entre buckets de Cloud Storage

• Metadatos de clave fija y personalizados: se conservan.
• Generación de objetos: se guarda como metadato personalizado x-goog-reserved-source-generation.
• Conservaciones: temporales se conservan por defecto; basadas en eventos no. Ojo con LCA: puedes conservarlas, pero evita crear objetos inaccesibles.
• Clase de almacenamiento: conservar, fijar una nueva o usar la del bucket de destino.
• Cifrado con CMEK: opcional conservar; por defecto se usa el método del bucket destino.
• timeCreated se puede conservar en customTime; updated no.
• Otros metadatos no editables (p. ej., etag, componentCount): no.

Listas de URL a Cloud Storage

• Campos de metadatos de clave fija: editables en destino.
• Content-Length y MD5: no editables y se conservan si la fuente los aporta.
• Marcas de tiempo de la fuente: no. Clase de almacenamiento: configurable.

POSIX a Cloud Storage (y viceversa)

• mtime se conserva como metadato personalizado goog-reserved-file-mtime.
• Tamaño se conserva como size. UID, GID, MODE y symlinks: opcionales via metadataOptions.
• En POSIX a POSIX, se pueden conservar UID/GID/MODE en archivos y carpetas; mtime se guarda para archivos (en carpetas se usa hora de creación en destino).

Estos detalles importan al mover datos entre servicios. No esperes que borrar un metadato en un sistema lo haga desaparecer mágicamente en otro; respeta las reglas de conservación de cada transferencia.

Metadatos en Compute Engine (VMs): límites y borrado, si usas Google Cloud

Aunque no es Drive, muchos equipos tocan metadatos de VMs en Compute Engine. Para gestionarlos necesitas permisos de IAM adecuados y conocer límites de tamaño y alcance.

Antes de nada: instala Google Cloud CLI y ejecútalo por primera vez con gcloud init (si usas un proveedor de identidad externo, inicia sesión federada). Mantén la CLI actualizada con gcloud components update y establece región y zona por defecto para evitar errores de ámbito.

Permisos necesarios típicos: si las VMs usan cuentas de servicio, se requiere iam.serviceAccounts.actAs. Para metadatos a nivel de proyecto: compute.projects.get y compute.projects.setCommonInstanceMetadata. Para metadatos zonales: compute.instanceSettings.get y compute.instanceSettings.update. Para metadatos en una VM concreta: compute.instances.get y compute.instances.setMetadata.

Límites clave: el conjunto de metadatos por VM tiene un máximo combinado de 512 KB; cada clave hasta 128 bytes y cada valor hasta 256 KB. Las claves SSH se guardan en ssh-keys; si superas el límite, toca limpiar claves en desuso. Si pones scripts de arranque/apagado como contenido directo, cuentan para el límite; en su lugar, guarda el script en Cloud Storage y proporciona solo la URL.

Mayúsculas/minúsculas: las claves diferencian mayúsculas; los valores también, salvo booleanos. Para metadatos zonales: solo se gestionan con gcloud o REST; no puedes duplicar claves con el mismo texto cambiando el caso (p. ej., crear ZONAL-METADATA-KEY si ya existe zonal-metadata-key); y no puedes definir valores zonales para ssh-keys.

Booleanos aceptan equivalentes: TRUE/FALSE y alternativas como Y/Yes/1 y N/No/0, sin distinguir mayúsculas o minúsculas.

Ámbitos y precedencias: el mismo nombre de clave puede existir a nivel de proyecto y zonal, pero el valor zonal prevalece en su zona. Si añades un valor zonal, se usa para las VMs de esa zona aunque haya valor a nivel de proyecto; añadir un valor de proyecto no pisa lo zonal existente.

Operaciones habituales: puedes configurar metadatos del proyecto (aplican a todas las VMs), metadatos zonales (afectan a todas las VMs de una zona en ese proyecto) y metadatos de instancia (solo para una VM). Para eliminar, gcloud o REST permiten quitar metadatos del proyecto, zonales o de instancia según corresponda.

Uso de REST en local: las muestras de API REST usan las credenciales que has dado a gcloud CLI. Autentica tu entorno y reutiliza esas credenciales para probar llamadas desde tu máquina.

Consejos prácticos para una higiene de metadatos más fina en Drive

Si lo que quieres es reducir huella en Drive, céntrate en lo controlable: etiquetas (quítalas si no aportan valor), texto indexable (ajústalo o vacíalo si no lo necesitas) y miniaturas (reemplázalas o evita subirlas). Las propiedades del sistema te sirven para auditar, no para borrar.

Cuando el archivo se comparte y no eres dueño, recuerda que quitarlo de tu vista no borra nada para los demás. Coordina con la persona propietaria si el objetivo es retirar por completo contenido o metadatos asociados.

Si integras Drive con flujos en Cloud Storage o con VMs, documenta expectativas. Muchos metadatos cambian o no viajan entre sistemas; evita automatismos que dependan de marcas de tiempo o ACLs que no se conservan.

Con estas pautas tendrás el control sobre lo que de verdad marca la diferencia. Gestiona etiquetas con precisión, cuida lo indexable y decide cuándo y cómo usar miniaturas para lograr un equilibrio entre privacidad, búsqueda y experiencia de uso.