Verifique el tamaño real de la memoria USB

28

Recientemente leí mucho sobre la tarjeta MicroSD falsa y las unidades de memoria USB que afirman tener mucho espacio (incluso si le preguntas a tu computadora), mientras que físicamente ofrecen mucho menos. Recientemente compré una unidad USB SanDisk (128 GB reclamados) y quiero probar su tamaño. No se compra a través de eBay o algo así, pero realmente quiero probar el tamaño real antes de usarlo productivamente.

Podría simplemente copiar cosas en él, copiarlo de nuevo y ver si los archivos están bien. También podría automatizarlo con Hashes y otras cosas. Pero esperaba que hubiera una solución más precisa. Leí que para Windows, H2testw hace el truco. ¿Hay una manera fácil de probar esto en Ubuntu / Linux? ¿Tal vez una herramienta especializada y que funcione bien?

Actualización: para ser claros, la idea es verificar que el tamaño que el controlador le dice al sistema Linux sea correcto ( para que no se pierdan datos ). No es que quiera ver si obtengo 128 GB en lugar de 127.3 GB. Quiero probar si todos los datos que escribo serán legibles nuevamente. Desafortunadamente, solo puedo encontrar información sobre esto en sitios de tecnología en inglés. Sin embargo, hay buenas fuentes alemanas. En realidad estoy buscando una aplicación como esas, pero para Ubuntu / Linux: https://www.raymond.cc/blog/test-and-detect-fake-or-counterfeit-usb-flash-drives-bought-from -ebay-with-h2testw /

Actualización2: Traté de reunir algunas fuentes en inglés. No los leí todos en detalle, debido al tiempo perdido.

Actualización3: Explicaciones

Debido a las extrañas críticas a continuación, algunas explicaciones.

¿Cuál es el problema y por qué dd solo no lo resuelve?

Esta es una reacción a

"Determine claramente cuál es el problema que está tratando de resolver y cuál es la definición de" disco falso "".

Parece que algunas personas no entienden el problema. Así que trato de explicarlo lo más brevemente posible en detalles, aunque creo que esto es muy extenso para mi pregunta.

La capacidad de los dispositivos usb que le proporcionan su sistema operativo o las herramientas de Unix puede ser incorrecta. Esto es fatal, ya que su sistema operativo regula la cantidad de datos a los que puede enviarlos. Envíe más datos de los que realmente puede contener, obtendrá una pérdida de datos. Esto es un problema. Entonces, ¿por qué puede suceder esto?

No necesita conocer bien el protocolo USB para comprender el problema. Las interfaces seriales tienen la propiedad común de que el dispositivo cliente (la unidad usb) necesitará indicar su propia capacidad a través de esta interfaz serial. Esto significa que el dispositivo cliente necesita su propio controlador con algún conocimiento sobre el propósito del dispositivo y, en este caso, su capacidad. También decide qué se hace, cuando recibe el comando para almacenar algo. Si el controlador está programado de esa manera, puede ignorar el comando o sobrescribir algo con los datos.

¿Qué significa esto? Lo que le digan sus herramientas Unix sobre la capacidad de la unidad: es lo que las herramientas le pidieron a la unidad, nada más. Para esto se inventó h2testw: prueba el tamaño real con un método explicado más adelante y lo compara con lo que dice la unidad. Si esto no es lo mismo, es posible que tenga una pérdida de datos, porque todas sus operaciones comunes para almacenar datos dependen de la información de su sistema operativo, que solo le pregunta al controlador. ¿Por qué solo preguntar? La prueba necesita tiempo y sobrescribe todos los datos en el disco. Por lo tanto, es natural que un sistema operativo necesite confiar en esta información.

Para verificar la capacidad real como h2testw, puede usar ddpara escribir datos en el disco, leerlo nuevamente y ver si es lo mismo que escribió. Totalmente legítimo La naturaleza del hardware y la unidad lo hacen más complicado. Considere escribir cachés por ejemplo. Debe asegurarse de no leer del caché. Este es solo un ejemplo de por qué no es tan fácil como parece. También piense que solo escribir ceros significa una baja entropía de información, que se puede reconstruir al leer. Simplemente no es tan fácil en detalle. Todavía puedes hacerlo manualmente, por supuesto.

¿Pero por qué, cuando puedes automatizar las cosas? ¿Por qué al trabajo? f3, como se propone en mi respuesta a continuación, implementa toneladas de pensamientos de muchos contribuyentes (considere que es una especie de h2testw extendido) y también implementa varios métodos con diferentes compensaciones. El desarrollador descubrió los trucos de diferentes unidades falsas (también conocidas como unidades falsificadas) que tenían a mano . Entonces, aunque entiendo la teoría y el problema (aparentemente porque los problemas están bien explicados en los medios tecnológicos alemanes, pero no en los medios de habla inglesa), no pretendo entender todo, por eso lo mencioné anteriormente. Es solo la teoría que entiendo, y soy más un tipo de software. Pero como estudiante de informática lo entiendo lo suficientemente bien como para ver el problema.

"Intenta comprender las utilidades básicas de Unix"

En realidad, ya respondí esto, pero para dejarlo claro: las herramientas de Unix solo usan el Protocolo USB (solo para dispositivos USB, por supuesto) para recopilar información. No tiene sentido hacer más que eso.

¿Ayuda comprar solo a proveedores de confianza?

TL; DR: no lo hace.

"Cuando se trata de comprar bienes, al igual que con cualquier forma de seguridad, considere encontrar un vendedor confiable y compre unidades solo de ellos".

¡La seguridad (y la seguridad) NO se trata de confiar! ¡Se trata de verificación y validación! Lo siento, pero esto está muy mal en muchos sentidos.

Suponga que compra a través de un vendedor de confianza. Unas cuantas preguntas:

  1. ¿El proveedor probó el hardware para asegurarse de que no haya pérdida de datos? ¿Reconoce cuándo compra discos falsos y los vende? No necesariamente.

  2. ¿Es posible que compre cosas que no sabe que son falsas? Totalmente, mire las recientes falsificaciones de ryzen: https://www.pcgamer.com/beware-of-fake-ryzen-processors-selling-on-amazon/ , https://www.heise.de/newsticker/meldung/ Direkt-von-Amazon-Faelschungen-von-AMDs-Ryzen-Prozessoren-im-Umlauf-3772757.html

  3. Si pierdo mi presentación en el disco y la arruino, ¿mi proveedor de confianza retrocederá en el tiempo y me rescatará? Probablemente reemplazará el disco, ya que el último viaje en el tiempo DeLorean fue destruido en 1885.

Otras cosas

"Esta pregunta realmente parece ser más como" promoción "para lo que le gusta a OP, y parece que OP está mucho menos interesado en probar las unidades".

Esto es ridículo. Estaba buscando específicamente una herramienta similar a h2testw que también se ejecute en Linux. Y sí, eso es lo que me gustaría, respuesta útil, lo siento mucho. No tenía idea de que la prensa de habla inglesa no es tan consciente de tales problemas y tuve la suerte de encontrar algo así más adelante. Esto no es una promoción, pero en realidad parece que podrías usar una.

verpfeilt
fuente
2
No tiene mucho sentido probarlo, ir por lo que la computadora dice que está disponible, o df --block-size=M. El límite de 4 GB sugeriría que es solo el límite de tamaño de archivo FAT32, no la capacidad de la unidad. Nunca obtendrá la capacidad total indicada, es un promedio solo para clasificarlo.
Sir_Scofferoff
66
Lo que la computadora dice que está disponible es justo lo que le dice el controlador de la unidad usb. Impulsiones falsas están mintiendo. Si tiene una capacidad de 4 GB pero afirma tener 512 GB, el resto que escribo se desechará o se sobrescribirá el espacio anterior, dependiendo del controlador. Entonces, de hecho, hay un punto en probarlo.
verpfeilt
esto es interesante. Nunca se me ocurrió la idea de falsificar el tamaño de un SSD, pero me gusta la idea de cómo escriben los datos y lo leen byte a byte para verificar la coherencia. Puedo ver cómo esto podría ser un problema y una herramienta como esta podría ser útil.
1
FakeFlashCheck también tiene un escaneo rápido. ¿Hay algún OSALT para eso?
neverMind9
PD: ya he encontrado f3probe. Mira mi comentario a continuación.
neverMind9

Respuestas:

34

f3 - Lucha contra el fraude flash

Solo encontré una alternativa, pero creo que esta es incluso mejor que la h2testwherramienta original para MS Windows. Afortunadamente, es realmente fácil de usar, incluso desde la línea de comandos. Sin embargo, hay GUI disponibles. También hay mucha información sobre la implementación y el problema con las unidades falsas en el sitio web de herramientas.

f3 ofrece dos métodos:

  • Método f3probe: mucho más rápido
  • Método h2testw: más lento. También pruebe el rendimiento R / W. Probablemente más confiable.

El método f3probe (recomendado)

f3probees una forma de probar las unidades, no tan precisa pero más rápida ya que no escribe en toda la unidad. Puede leer más al respecto en el sitio web de herramientas. Si quieres estar 100% seguro, mejor usa el método h2testw. Como el desarrollador describe en el sitio web:

f3probe es la forma más rápida de identificar unidades falsas y sus tamaños reales.

Y:

Finalmente, gracias a que f3probe es software libre, y una vez que f3probe está probado en batalla, f3probe podría integrarse en teléfonos inteligentes, cámaras, reproductores de MP3 y otros dispositivos para detener de una vez por todas la proliferación de flash falso.

También hay un ejemplo de uso en el sitio web:

Advertencia : ¡Esto destruirá cualquier dato previamente almacenado en su disco!

$ sudo f3probe --destructive --time-ops /dev/sdb
[sudo] password for michel: 
F3 probe 6.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing may **demolish data,** so it is more suitable for flash drives out of the box, without files being stored yet. The process normally takes from a few seconds to 15 minutes, but
         it can take longer. Please be patient. 

Bad news: The device `/dev/sdb' is a counterfeit of type limbo

You can "fix" this device using the following command:
f3fix --last-sec=16477878 /dev/sdb

Device geometry:
             *Usable* size: 7.86 GB (16477879 blocks)
            Announced size: 15.33 GB (32155648 blocks)
                    Module: 16.00 GB (2^34 Bytes)
    Approximate cache size: 0.00 Byte (0 blocks), need-reset=yes
       Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 1'13"
 Operation: total time / count = avg time
      Read: 472.1ms / 4198 = 112us
     Write: 55.48s / 2158 = 25.7ms
     Reset: 17.88s / 14 = 1.27s

Tenga en cuenta que también devuelve un comando que le permite usar la unidad con su tamaño real f3fix.

La herramienta f3fix

f3fix crea una partición que se ajusta al tamaño real de la unidad falsa. Utilice f3probela salida de para determinar los parámetros para i3fix

sudo f3fix --last-sec=16477878 /dev/sdb

El método h2testw / Prueba de rendimiento con f3read / f3write

F3 es una colección de herramientas que se ocupan de unidades flash falsas. Dos de ellos implementan juntos el h2testwMétodo:

f3write [--start-at=NUM] [--end-at=NUM] <PATH>
f3read  [--start-at=NUM] [--end-at=NUM] <PATH>

f3writepedirá el tamaño reclamado de los dispositivos y lo llenará con archivos generados con un tamaño de 1 gb cada uno. f3readleerá todos esos archivos y verá que están completos y no rotos. Como ejemplo, los comandos que utilicé para probar mi unidad flash de ~ 128 gb:

$ f3write /media/username/1EB8021AB801F0D7/
Free space: 117.94 GB
Creating file 1.h2w ... OK!                           
...
Creating file 118.h2w ... OK!                         
Free space: 0.00 Byte
Average writing speed: 11.67 MB/s

Ahora para probar si los archivos están almacenados correctamente:

$ f3read /media/username/1EB8021AB801F0D7/
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
...
Validating file 118.h2w ... 1979488/        0/      0/      0

  Data OK: 117.94 GB (247346272 sectors)
Data LOST: 0.00 Byte (0 sectors)
           Corrupted: 0.00 Byte (0 sectors)
    Slightly changed: 0.00 Byte (0 sectors)
         Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 32.38 MB/s

La prueba para una unidad de este tamaño tomó alrededor de tres horas con este método y, a veces, causó una gran carga de disco en mi computadora, pero se me dice que es la más precisa.

Instalar en Ubuntu

En terminal:

sudo apt install f3

Esto le llevará: f3brew, f3fix, f3probe, f3read, f3writecon sus páginas man.

Estas herramientas son parte del f3paquete, que al menos está disponible en Ubuntu 15.10. Según el sitio web, hay algunas herramientas más que están disponibles. Para obtenerlos, eche un vistazo al sitio web.
El paquete viene con páginas de manual cortas pero útiles, aunque creo que pierden información del sitio web sobre la diferencia de f3read / write y f3probe por ejemplo, por lo que esta respuesta se hizo un poco más larga.

verpfeilt
fuente
2
Gracias por presentar esta gran herramienta. Solo quiero agregar que la instalación usando apt-getse instalará f3ready fwrite solo como f3probey f3fixse consideran experimentales. Si desea usarlos, tendrá que construirlos desde la fuente usando make experimentaldespués de instalar sus dependencias sudo apt-get install libudev1 libudev-dev libparted0-dev. Ver github.com/AltraMayor/f3#the-extra-applications-for-linux
Ahmed Essam
1
"[f3probe] ya no es experimental, sino que solo está disponible en Linux". github.com/AltraMayor/f3/issues/78#issuecomment-378599141
verpfeilt
4

He escrito una herramienta simple para eso, se llama CapacityTester (captura de pantalla) y tiene una GUI y una CLI.

Hay un binario precompilado para Debian 7 disponible para descargar , que es muy probable que funcione de inmediato en un sistema Ubuntu moderno.

Lo escribí para mi uso personal porque no pude encontrar una herramienta gráfica para este propósito. Solo necesita montar su unidad flash USB vacía primero, seleccionarla e iniciar la prueba. Es una herramienta muy tonta porque todo lo que hace es llenar el disco con archivos y luego verificar que los datos en el disco sean correctos. Anulará la prueba en el primer error (escribir o leer / verificar). Informará el desplazamiento del fragmento que no se pudo escribir o verificar con éxito, pero este es un desplazamiento lógico, por lo que esta información puede ser inútil porque depende del sistema de archivos donde se encuentran los archivos en la unidad. Sin embargo, cuando la unidad se ha llenado de datos y todo se puede leer y verificar, debe ser seguro asumir que la capacidad informada de la unidad es correcta. Como nota al margen,

De nuevo, es muy simple, ya que solo funciona con archivos en la parte superior de un sistema de archivos existente. Por lo tanto, hay algunos KB (búfer de + 1M) que no se pueden probar. Y es muy lento porque realmente llena todo el sistema de archivos. F3 es ciertamente mucho más sofisticado y también más rápido, pero no tiene GUI. La única razón por la que existe CapacityTester es porque tiene una GUI para que pueda ser utilizada por usuarios que no están familiarizados con la línea de comandos o que simplemente prefieren una GUI.

Los comentarios son apreciados.

c0xc
fuente
Como se indica en el sitio web de los desarrolladores, hay una GUI QT y una GUI para OSX disponible (no las probé). Sin embargo, creo que se basa en QT4. ¿Por qué no usar F3 como backend también? No haría su herramienta más complicada y probablemente la haría más funcional / efectiva, utilizando el conocimiento que se gastó en F3.
verpfeilt el
-6

Abordar el comportamiento de OP y el "disco falso"

Estoy editando la respuesta para abordar adecuadamente algunos puntos, ya que OP ha sido muy vehemente (y en mi opinión, me opongo a la mayoría de los comentarios y respuestas, excepto a los suyos, lo que me parece sospechoso). Particularmente, hay muchas afirmaciones de que existe un "disco falso", pero no hay una definición clara de lo que en realidad significa. OP declaró:

Podría simplemente copiar cosas en él, copiarlo de nuevo y ver si los archivos están bien. También podría automatizarlo con Hashes y otras cosas. Pero esperaba que hubiera una solución más precisa.

OP admitieron que "simplemente podían copiar cosas" y verificar la integridad de los datos, pero estaban muy en contra de todos los demás comentarios y respuestas que proponían algo más, y OP solo siguió presionando a F3 como el "verdadero negocio". La pregunta en sí comenzó al principio sobre el tamaño de la unidad, pero luego OP por cualquier razón mencionó hashes para "ver si los archivos están bien", como si hubiera unidades misteriosas que reclaman un tamaño y le permiten escribir ese tamaño, pero entonces los datos están corruptos. Por lo tanto, me parece muy sospechoso y consideraría OP promoviendo F3 como preguntas y respuestas de spam.

Cuando una unidad es realmente una unidad falsa

En la pregunta, la definición aparente de OP es

"... unidades que dicen tener mucho espacio (a menudo llevadas demasiado lejos, como 128 GB), mientras que físicamente ofrecen solo 0.5 a 4 GB".

En otras palabras, según OP, el controlador reclama X cantidad de datos, pero USB solo puede contener algo como 80-90% menos de lo que se reclama.

El usuario sudodus propuso en los comentarios (énfasis agregado): "He encontrado que varios pendrives USB son ligeramente más pequeños que el tamaño nominal. Los llamo de tamaño insuficiente . Creo que las unidades falsas son 'sustancialmente más pequeñas' (generalmente la mitad del tamaño nominal) o menos ) ". Esta definición es excelente, sin embargo, si tomamos eso, el disco falso se define al 50%. Una unidad que reclama 64 GB pero solo puede contener 32 GB, técnicamente pierde la mitad de su valor para el propietario y el propietario solo puede poner la mitad de lo que pretendía en la unidad.

Propongo una definición más simple: el dispositivo de almacenamiento falsificado es el que dice tener Claimed Sizepero está por debajo del 15% de tolerancia (y la tolerancia es Claimed Size ± 15 %).

El ± 15 %es muy razonable. Tenga en cuenta también que los usuarios suelen estar confundidos entre las organizaciones Unix, IEEE e IEC que usan el prefijo binario en lugar de la potencia de 10 prefijos para el tamaño de almacenamiento de datos. La diferencia llega al 20% en el nivel de prefijo yotta, sin embargo, las unidades USB aún no están allí, por lo que para los próximos 20 años el 15 por ciento es razonable. (Ver pregunta de askubuntu "Significado de 'i' en 'MiB'" y Prefijo Binario )

Prueba de la unidad

Efectivamente, el usuario no necesita ninguna herramienta especial, aparte de lo que ya viene con Ubuntu y la mayoría de los sistemas Unix compatibles con POSIX. Enfaticemos y reformulemos la definición nuevamente:

Si no podemos escribir la cantidad de datos para conducir y lo que escribimos está dentro del 15% de tolerancia, entonces la unidad está bien

La forma más sencilla de hacerlo es con dd, simplemente sobrescribir el dispositivo con ceros (y, por supuesto, recuerde guardar sus archivos antes de hacerlo).

sudo dd if=/dev/zero of=/dev/sdb1 iflag=nocache oflag=direct bs=1                        

Tenga en cuenta el bs=1tamaño del bloque de 1 byte. El ddcomando generalmente proporciona un informe de cuánto se escribe.

$ dd if=/dev/zero of=/dev/null bs=1 count=1024
1024+0 records in
1024+0 records out
1024 bytes (1.0 kB, 1.0 KiB) copied, 0.00261981 s, 391 kB/s

Le pedimos que escribiera 1024 bytes, escribió 1024 bytes.

La lista más precisa de los pasos que se adhieren a la definición sería:

  • Calcule cuántos datos reclama la unidad (suponiendo que sospeche dfque está "equivocada"). En este ejemplo, supongamos que /dev/sdb1es el archivo de mi dispositivo para unidad USB:

    $ df -P /dev/sdb1 | awk 'NR==2{print $2}'
    115247656
    

    Tenga en cuenta que el -Pindicador es para la portabilidad POSIX, lo que significa que el tamaño del bloque de datos será de 1024 bytes, y eso significa que hay 115247656 * 1024 bytes en esa unidad.

  • Averigüe cuál es la tolerancia del 15% por debajo de lo que afirma la unidad (115247656), tal vez use una utilidad que admita el cálculo de coma flotante como awk:

     $ awk 'BEGIN{printf "%d\n",115247656*(1-0.15)}'
     97960507
    
  • Cree datos aleatorios en el disco duro del mismo tamaño que la unidad en el paso anterior para usar como punto de referencia: dd if=/dev/urandom of=./mytestfile.random bs=1024 count=97960507

  • Ahora escribe datos dd if=./mytestfile.random of=/dev/sda1. Si el disco puede aguantar tanto, es "real". También puede tomar md5sumo sha1sumde ./mytestfile.randomy comparar con /dev/sda1ahora. Una mejora aún mejor sería escribir el punto mytestfile.randomde montaje del archivo, manteniendo así el sistema de archivos en la unidad y sin alterar la partición de la unidad, en otras palabras.

    dd if=./mytestfile.random of=/mountpoint/for/usb/drive/testfile.random
    
  • Para la integridad continuación, puede simplemente hacer ninguna verificación hashsum, tales como md5sum, sha1sum, sha256sumu otros. Por ejemplo

    md5sum ./mytestfile.random  /mountpoint/for/usb/drive/testfile.random
    

    El punto clave aquí es que si la cantidad de datos escritos está dentro de la tolerancia y produce una suma de verificación correcta antes y después de la escritura, la unidad probablemente esté bien.

Todo esto se puede poner en un buen guión por conveniencia, si así lo desea.

Conclusión

Esta pregunta realmente parece ser más como "promoción" para lo que le gusta a OP, y parece que OP está mucho menos interesado en probar las unidades. Además, el problema en sí es más humano que el problema de "unidad". En los comentarios, OP ellos mismos declararon que realmente no entienden el comportamiento de USB, pero son vehementemente culpables de "el controlador". Dejaré esta pregunta con 3 puntos:

  • Averigüe claramente cuál es el problema que está tratando de resolver y cuál es la definición de "disco falso".
  • Intenta comprender las utilidades básicas de Unix
  • Cuando se trata de comprar bienes, al igual que con cualquier forma de seguridad, considere encontrar un vendedor confiable y compre unidades solo de ellos.
Sergiy Kolodyazhnyy
fuente
1
Gracias, pero no estoy seguro si dd detectaría el tamaño real, porque el controlador fingiría que tiene tanto espacio. Creo que tiene que escribir en un archivo (o más archivos) y verificar si puede recuperarlo por completo. Supongo que hay una razón por la cual hay herramientas dedicadas para realizar pruebas, desafortunadamente solo se trata de Windows. Supongo que tendré que usar una VM. Bueno, fue bastante importante en las noticias en Alemania hace un tiempo. (Fuente alemana sobre el tema: heise.de/ct/ausgabe/… )
verpfeilt el
1
@verpfeilt Bueno, no hablo alemán, por lo que el artículo tendrá que ser resumido o traducido por alguien. ¿Cómo fingiría el controlador que tiene la misma cantidad de espacio? ddinforma la cantidad de datos que ha escrito / dado al dispositivo, no veo cómo se puede falsificar.
Sergiy Kolodyazhnyy
2
Bueno, puedes escribir todo, pero eso no dice que el cliente usb lo almacenará. Si entendí correctamente, el problema radica directamente en la arquitectura usb. No puede simplemente pegarle un poco de memoria flash, sino que necesita un chip que cumpla con el protocolo. Como un stub ( en.wikipedia.org/wiki/Method_stub ), esto le permite construir una memoria de solo escritura (sin embargo, la unidad tiene una pequeña cantidad de memoria para almacenar archivos pequeños). Por eso existen herramientas como h2testw. Aquí hay algo en inglés: myce.com/news/…
verpfeilt el
1
@SergiyKolodyazhnyy, he encontrado que varios pendrives USB son ligeramente más pequeños que el tamaño nominal. Los llamo de tamaño insuficiente . Creo que las unidades falsas son 'sustancialmente más pequeñas' (generalmente la mitad del tamaño nominal o menos). Supongo que escribir algo en el disco ddy luego verificar el md5sum debería verificar cuánto se podría escribir y leer correctamente. (Creo que las herramientas especiales en la respuesta de @ verpfeilt parecen más atractivas, pero no las he probado. Tengo muchos pendrives USB y tarjetas de memoria, no creo que haya comprado una falsa todavía.)
sudodus
1
@SergiyKolodyazhnyy, estoy de acuerdo con su definición actualizada, 'el dispositivo de almacenamiento falsificado es el que afirma tener un tamaño reclamado pero está por debajo del 15% de tolerancia (y la tolerancia es el tamaño reclamado ± 15%)'. - Gracias por una excelente actualización de su respuesta :-)
sudodus