[opensuse-es] Thunderbird: archivo "inbox" de 650 MiB
Hola, Estoy con Icedove 2.0.0.22 (Thunderbird para los amigos) y veo que el archivo "inbox" ocupa 650 MiB. El problema es que en la bandeja de entrada sólo tengo un correo que ni siquiera tiene texto en el cuerpo del mensaje, sólo en el asunto, así que no puede ocupar 650 MiB. Ya sé que puedo mover ese archivo y que se regenere automáticamente (vacío) pero es que no sé qué correos hay en esos 650 MiB, ni si los necesito, ni si están en otras carpetas. No sé ni cómo ni por qué se ha generado un archivo de semejante tamaño cuando la bandeja de entrada esta casi vacía... salvo que se vaya "cacheando" automáticamente todo lo que entra, lo cual sería una barbaridad, pero cosas más raras he visto... ¿Alguna idea? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Tue, 23 Feb 2010 20:14:21 +0000, Camaleón escribió: (...)
No sé ni cómo ni por qué se ha generado un archivo de semejante tamaño cuando la bandeja de entrada esta casi vacía... salvo que se vaya "cacheando" automáticamente todo lo que entra, lo cual sería una barbaridad, pero cosas más raras he visto...
¿Alguna idea?
Argh. La acabo de compactar y ahora ocupa 3 KiB. Pensaba que "compactar" sólo funcionaba con cuentas y directorios IMAP. No me puedo creer que estuviera (¡¡esté!!) cacheando _todos los correos_ que han pasado por la bandeja de entrada... eso es una locura >:-( ¿Tengo que ir compactando *todas y cada una de las carpetas* para que elimine los correos que yo he seleccionado para borrar pero que realmente no han sido eliminados? Parece un mal chiste... Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón escribió:
El Tue, 23 Feb 2010 20:14:21 +0000, Camaleón escribió:
(...)
No sé ni cómo ni por qué se ha generado un archivo de semejante tamaño cuando la bandeja de entrada esta casi vacÃa... salvo que se vaya "cacheando" automáticamente todo lo que entra, lo cual serÃa una barbaridad, pero cosas más raras he visto...
¿Alguna idea?
Argh. La acabo de compactar y ahora ocupa 3 KiB. Pensaba que "compactar" sólo funcionaba con cuentas y directorios IMAP.
No me puedo creer que estuviera (¡¡esté!!) cacheando _todos los correos_ que han pasado por la bandeja de entrada... eso es una locura >:-(
¿Tengo que ir compactando *todas y cada una de las carpetas* para que elimine los correos que yo he seleccionado para borrar pero que realmente no han sido eliminados?
Parece un mal chiste...
Saludos,
Buenas... Hay un plugin , con buena configuración para eso y se llama: xpunge https://addons.mozilla.org/en-US/thunderbird/addon/1279 ojo, que esta version al parecer solo anda con Thunderbird 3.. en todo caso, me avisas y te envio alguna version anterior Saludos y Suerte -- Walter www.infoquil.com.ar -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Tue, 23 Feb 2010 20:04:39 -0300, Walter escribió:
Camaleón escribió:
(...)
¿Tengo que ir compactando *todas y cada una de las carpetas* para que elimine los correos que yo he seleccionado para borrar pero que realmente no han sido eliminados?
Parece un mal chiste...
Buenas... Hay un plugin , con buena configuración para eso y se llama: xpunge
https://addons.mozilla.org/en-US/thunderbird/addon/1279
ojo, que esta version al parecer solo anda con Thunderbird 3.. en todo caso, me avisas y te envio alguna version anterior
Después de leer esto: *** http://kb.mozillazine.org/Compacting_folders However, it is best to not to do anything in Thunderbird except read messages if you notice that compacting has started. If you tag, mark, or move messages during compacting, this can cause folder corruption and data loss. In addition, if you are in the process of writing an email while compacting starts, you may get an error when you try to save or send it. (This can be especially annoying if you're responding to an email with interleaved replies because copy-pasting to a new message will often move quotation marks into the middle of lines in quoted sections). *** Mejor lo hago de forma manual. Gracias de todas formas :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-02-23 a las 22:50 -0000, Camaleón escribió:
El Tue, 23 Feb 2010 20:14:21 +0000, Camaleón escribió:
(...)
No sé ni cómo ni por qué se ha generado un archivo de semejante tamaño cuando la bandeja de entrada esta casi vacía... salvo que se vaya "cacheando" automáticamente todo lo que entra, lo cual sería una barbaridad, pero cosas más raras he visto...
¿Alguna idea?
Argh. La acabo de compactar y ahora ocupa 3 KiB. Pensaba que "compactar" sólo funcionaba con cuentas y directorios IMAP.
Al revés, sólo funciona con los mbox. Mejor dicho, se diseñó para los mbox.
No me puedo creer que estuviera (¡¡esté!!) cacheando _todos los correos_ que han pasado por la bandeja de entrada... eso es una locura >:-(
¿Tengo que ir compactando *todas y cada una de las carpetas* para que elimine los correos que yo he seleccionado para borrar pero que realmente no han sido eliminados?
Efectivamente.
Parece un mal chiste...
Creo que hay una opción para que compacte automáticamente en determinadas circunstancias. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkuEc4QACgkQtTMYHG2NR9VULwCeLwPKdhwlpPUE3NfNIh3h7kRE IcUAoI0/ei0/PTz0VW83NpSqhLYuUijy =Ugv2 -----END PGP SIGNATURE-----
El Wed, 24 Feb 2010 01:32:01 +0100, Carlos E. R. escribió:
El 2010-02-23 a las 22:50 -0000, Camaleón escribió:
El Tue, 23 Feb 2010 20:14:21 +0000, Camaleón escribió:
(...) Argh. La acabo de compactar y ahora ocupa 3 KiB. Pensaba que "compactar" sólo funcionaba con cuentas y directorios IMAP.
Al revés, sólo funciona con los mbox. Mejor dicho, se diseñó para los mbox.
Bueno, el KMail también compactaba (no sé si lo llamaba así, pero efectuaba labores de mantenimiento de las carpetas) usando maildir. Pero lo hacía él solo, automáticamente y sin molestar. Y también hay que compactar los correos de las cuentas IMAP para poder eliminarlos. En la 3.x se ha mejorado este tema.
No me puedo creer que estuviera (¡¡esté!!) cacheando _todos los correos_ que han pasado por la bandeja de entrada... eso es una locura
:-(
¿Tengo que ir compactando *todas y cada una de las carpetas* para que elimine los correos que yo he seleccionado para borrar pero que realmente no han sido eliminados?
Efectivamente.
Qué chapuza...
Parece un mal chiste...
Creo que hay una opción para que compacte automáticamente en determinadas circunstancias.
Que no voy a activar ni harta de vino. La explicación en la respuesta a Walter. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 02/24/2010 08:10 AM, Camaleón wrote:
El Wed, 24 Feb 2010 01:32:01 +0100, Carlos E. R. escribió:
¿Tengo que ir compactando *todas y cada una de las carpetas* para que elimine los correos que yo he seleccionado para borrar pero que realmente no han sido eliminados?
Efectivamente.
Qué chapuza...
Es cuestión del tipo de la definición de lo que es el formato mbox, y de su implementación por thunderbird. Con Alpine no existe ese problema.
Creo que hay una opción para que compacte automáticamente en determinadas circunstancias.
Que no voy a activar ni harta de vino. La explicación en la respuesta a Walter.
La ví. -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Martes, 23 de Febrero de 2010 23:50:29 Camaleón escribió:
El Tue, 23 Feb 2010 20:14:21 +0000, Camaleón escribió:
(...)
No sé ni cómo ni por qué se ha generado un archivo de semejante tamaño cuando la bandeja de entrada esta casi vacía... salvo que se vaya "cacheando" automáticamente todo lo que entra, lo cual sería una barbaridad, pero cosas más raras he visto...
¿Alguna idea?
Argh. La acabo de compactar y ahora ocupa 3 KiB. Pensaba que "compactar" sólo funcionaba con cuentas y directorios IMAP.
No me puedo creer que estuviera (¡¡esté!!) cacheando _todos los correos_ que han pasado por la bandeja de entrada... eso es una locura >:-(
¿Tengo que ir compactando *todas y cada una de las carpetas* para que elimine los correos que yo he seleccionado para borrar pero que realmente no han sido eliminados?
Parece un mal chiste...
Saludos,
-- Camaleón
debe haber un compactar autmaticamente ¿no? -- No imprima este correo si no es necesario. El medio ambiente está en nuestras manos. __________________________________________ Clist UAH a.k.a Angel __________________________________________ Artista -- (internet) --> Usuario final. Así los artistas cobran más y dicen menos paridas sobre lo que creen que es la piratería. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Martes, 23 de Febrero de 2010 21:14:21 Camaleón escribió:
Hola,
Estoy con Icedove 2.0.0.22 (Thunderbird para los amigos) y veo que el archivo "inbox" ocupa 650 MiB.
El problema es que en la bandeja de entrada sólo tengo un correo que ni siquiera tiene texto en el cuerpo del mensaje, sólo en el asunto, así que no puede ocupar 650 MiB.
Ya sé que puedo mover ese archivo y que se regenere automáticamente (vacío) pero es que no sé qué correos hay en esos 650 MiB, ni si los necesito, ni si están en otras carpetas.
No sé ni cómo ni por qué se ha generado un archivo de semejante tamaño cuando la bandeja de entrada esta casi vacía... salvo que se vaya "cacheando" automáticamente todo lo que entra, lo cual sería una barbaridad, pero cosas más raras he visto...
¿Alguna idea?
Saludos,
-- Camaleón
Es un archivo tipo mbox ¿no? con maildir no tendrias un solo archivo... tendrás que purgar el "mbox" Thunderbird debe tener una opcion por ahí, para hacerlo Lo que pasa es que el archivo engorda cada vez que mencionamos la palabra KDE seguid de un numero mayor que 3.5 :-P Salu2 -- No imprima este correo si no es necesario. El medio ambiente está en nuestras manos. __________________________________________ Clist UAH a.k.a Angel __________________________________________ MySQL4: Bien, Usa transacciones solo si no necesitas velocidad. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 02/24/2010 10:19 AM, Angel Alvarez wrote:
Es un archivo tipo mbox ¿no? con maildir no tendrias un solo archivo...
No es una opción con thunderbird. -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Tuesday 23 February 2010 21:14:21 Camaleón wrote:
Hola,
Estoy con Icedove 2.0.0.22 (Thunderbird para los amigos) y veo que el archivo "inbox" ocupa 650 MiB.
El problema es que en la bandeja de entrada sólo tengo un correo que ni siquiera tiene texto en el cuerpo del mensaje, sólo en el asunto, así que no puede ocupar 650 MiB.
Ya sé que puedo mover ese archivo y que se regenere automáticamente (vacío) pero es que no sé qué correos hay en esos 650 MiB, ni si los necesito, ni si están en otras carpetas.
No sé ni cómo ni por qué se ha generado un archivo de semejante tamaño cuando la bandeja de entrada esta casi vacía... salvo que se vaya "cacheando" automáticamente todo lo que entra, lo cual sería una barbaridad, pero cosas más raras he visto...
¿Alguna idea?
Saludos,
-- Camaleón
Editar-Preferencias-Avanzadas - Red y Espacio en disco habilita compactar cuando ahorres tanto espacio en disco. Es bueno que cuando borres no los borres hasta que compactes, por esa caracteristica mucha gente se ha librado de problemas. Si borras y no compactas siempre puedes recuperar el correo que quieras. saludos -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Wed, 24 Feb 2010 10:25:15 +0100, francisco f escribió: Aviso, entrando en modo "ultra-ranting"...
On Tuesday 23 February 2010 21:14:21 Camaleón wrote:
No sé ni cómo ni por qué se ha generado un archivo de semejante tamaño cuando la bandeja de entrada esta casi vacía... salvo que se vaya "cacheando" automáticamente todo lo que entra, lo cual sería una barbaridad, pero cosas más raras he visto...
Editar-Preferencias-Avanzadas - Red y Espacio en disco habilita compactar cuando ahorres tanto espacio en disco.
Pero es peligroso hacerlo online :-(
Es bueno que cuando borres no los borres hasta que compactes,
¿Bueno "para quién"? >:-) Para mí no, desde luego. Para el maldito e ineficiente formato mbox, supongo que sí.
por esa caracteristica mucha gente se ha librado de problemas. Si borras y no compactas siempre puedes recuperar el correo que quieras.
Arrrhgg, pero eso no tiene sentido alguno, ¡estamos en el año 2010! y / exijo/ cierta eficiencia y automatismo en un cliente de correo :-) - Vale que el formato mbox es una porquería, aceptado. - Vale que Thundercito lo use porque, porque... ¿porque le sale de cierto sitio? porque no veo otro motivo para no admitir al menos 2 formatos: maidir y mbox. No digo que den soporte a 20 formatos de almacenamiento distintos, pero sí los más usados. Lo que "no vale" es que: 1/ A día de hoy sea preciso compactar las carpetas 2/ A día de hoy la operación de compactación sea peligrosa hacerla online (¿tengo que estar pendiente de qué hago o dejo de hacer porque "el señor cliente de correo" está en una operación de compactado?) 3/ No permita seleccionar las carpetas en las que se quiera desactivar esa opción de "cacheo masivo" e indiscriminado. Señores, por mi bandeja de entrada (y por la millones de personas) entran correos espantosamente enormes (no es culpa mía que alguien me envíe correos de 20/30/40 MiB). Y cuando borro un mensaje, espero que se vaya a la papelera (ya lo recuperaré de ahí en caso de que lo necesite). Pues no, hala, a eliminar *y a compactar* toca -dos acciones por una, que hay rebajas-, porque no lo puedo desactivar y los mensajes de cachean, sí o sí. Para qué narices quiero 8 GiB de ram, un sistema de 64 bits y un micro con 4 núcleos si el Thundercito de las "#ðßðłł↓ŧ←ħŋ" y su formato mbox "sufre tanto" (huys pobrescillooo) al eliminar contenido de un archivo. Claro, como es una operación "tan intensiva" no puede hacerlo en tiempo real. Tiene que "falsear datos", eliminar pero "no eliminar", usar técnicas "de ocultación"... :-P Hala, ya está, ya me he desquitado :-) Nota: el correo es sólo una pataleta por el casi /1 GiB/ que he liberado tras empezar a compactar compulsivamente el resto de carpetas. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Miércoles, 24 de Febrero de 2010 11:30:40 Camaleón escribió:
El Wed, 24 Feb 2010 10:25:15 +0100, francisco f escribió:
Aviso, entrando en modo "ultra-ranting"...
On Tuesday 23 February 2010 21:14:21 Camaleón wrote:
No sé ni cómo ni por qué se ha generado un archivo de semejante tamaño cuando la bandeja de entrada esta casi vacía... salvo que se vaya "cacheando" automáticamente todo lo que entra, lo cual sería una barbaridad, pero cosas más raras he visto...
Editar-Preferencias-Avanzadas - Red y Espacio en disco habilita compactar cuando ahorres tanto espacio en disco.
Pero es peligroso hacerlo online :-(
Es bueno que cuando borres no los borres hasta que compactes,
¿Bueno "para quién"? >:-)
Para mí no, desde luego. Para el maldito e ineficiente formato mbox, supongo que sí.
por esa caracteristica mucha gente se ha librado de problemas. Si borras y no compactas siempre puedes recuperar el correo que quieras.
Arrrhgg, pero eso no tiene sentido alguno, ¡estamos en el año 2010! y / exijo/ cierta eficiencia y automatismo en un cliente de correo :-)
- Vale que el formato mbox es una porquería, aceptado.
- Vale que Thundercito lo use porque, porque... ¿porque le sale de cierto sitio? porque no veo otro motivo para no admitir al menos 2 formatos: maidir y mbox. No digo que den soporte a 20 formatos de almacenamiento distintos, pero sí los más usados.
Lo que "no vale" es que:
1/ A día de hoy sea preciso compactar las carpetas
2/ A día de hoy la operación de compactación sea peligrosa hacerla online (¿tengo que estar pendiente de qué hago o dejo de hacer porque "el señor cliente de correo" está en una operación de compactado?)
3/ No permita seleccionar las carpetas en las que se quiera desactivar esa opción de "cacheo masivo" e indiscriminado.
Señores, por mi bandeja de entrada (y por la millones de personas) entran correos espantosamente enormes (no es culpa mía que alguien me envíe correos de 20/30/40 MiB). Y cuando borro un mensaje, espero que se vaya a la papelera (ya lo recuperaré de ahí en caso de que lo necesite). Pues no, hala, a eliminar *y a compactar* toca -dos acciones por una, que hay rebajas-, porque no lo puedo desactivar y los mensajes de cachean, sí o sí.
Para qué narices quiero 8 GiB de ram, un sistema de 64 bits y un micro con 4 núcleos si el Thundercito de las "#ðßðłł↓ŧ←ħŋ" y su formato mbox "sufre tanto" (huys pobrescillooo) al eliminar contenido de un archivo. Claro, como es una operación "tan intensiva" no puede hacerlo en tiempo real. Tiene que "falsear datos", eliminar pero "no eliminar", usar técnicas "de ocultación"... :-P
Hala, ya está, ya me he desquitado :-)
Nota: el correo es sólo una pataleta por el casi /1 GiB/ que he liberado tras empezar a compactar compulsivamente el resto de carpetas.
Saludos,
-- Camaleón
Eso te pasa por llamarle thundercito y demás, Con tantos cariñitos le tienes mal acostumbrado :-P Salu2 -- No imprima este correo si no es necesario. El medio ambiente está en nuestras manos. __________________________________________ Clist UAH a.k.a Angel __________________________________________ Mas vale POJO en mano que STRUTS volando. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Wed, 24 Feb 2010 12:04:11 +0100, Angel Alvarez escribió:
El Miércoles, 24 de Febrero de 2010 11:30:40 Camaleón escribió:
Aviso, entrando en modo "ultra-ranting"...
Eso te pasa por llamarle thundercito y demás, Con tantos cariñitos le tienes mal acostumbrado :-P
Esa /mala costumbre/ me la "pegó" don francisco f, precisamente >:-) Pero tienes razón, a partir de ahora lo llamaré "palomino" >>:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Wednesday 24 February 2010 11:30:40 Camaleón wrote:
El Wed, 24 Feb 2010 10:25:15 +0100, francisco f escribió:
Aviso, entrando en modo "ultra-ranting"...
On Tuesday 23 February 2010 21:14:21 Camaleón wrote:
No sé ni cómo ni por qué se ha generado un archivo de semejante tamaño cuando la bandeja de entrada esta casi vacía... salvo que se vaya "cacheando" automáticamente todo lo que entra, lo cual sería una barbaridad, pero cosas más raras he visto...
Editar-Preferencias-Avanzadas - Red y Espacio en disco habilita compactar cuando ahorres tanto espacio en disco.
Pero es peligroso hacerlo online :-(
¿Por? cuando compacta el thundercito bloquea cualquier otro acceso a los ficheros y hasta que no acaba no puedes hacer nada. Naturalmente si se te cae el ordeñador pos mal vamos, pero aun asi se puede recuperar algo. Y tengo unos cuantos asi, y nunca ha fallado (joder como falle ahora sus enterareis)
Es bueno que cuando borres no los borres hasta que compactes,
¿Bueno "para quién"? >:-)
Para mi, hay mucho iluminado manazas que borar y borra y borra, luego tienes que hacer milagros para recuperarle el super correo que borro.
Para mí no, desde luego. Para el maldito e ineficiente formato mbox, supongo que sí.
por esa caracteristica mucha gente se ha librado de problemas. Si borras y no compactas siempre puedes recuperar el correo que quieras.
Arrrhgg, pero eso no tiene sentido alguno, ¡estamos en el año 2010! y / exijo/ cierta eficiencia y automatismo en un cliente de correo :-)
Si lo quieres automatico pues lo pones, que te pregunte o que no.
- Vale que el formato mbox es una porquería, aceptado.
- Vale que Thundercito lo use porque, porque... ¿porque le sale de cierto sitio? porque no veo otro motivo para no admitir al menos 2 formatos: maidir y mbox. No digo que den soporte a 20 formatos de almacenamiento distintos, pero sí los más usados.
Lo que "no vale" es que:
1/ A día de hoy sea preciso compactar las carpetas
Pues si es por mi no quitaria la funcion.
2/ A día de hoy la operación de compactación sea peligrosa hacerla online (¿tengo que estar pendiente de qué hago o dejo de hacer porque "el señor cliente de correo" está en una operación de compactado?) >
pos no se que decirte, cuando a mi me compacta bloquea las demas operaciones
3/ No permita seleccionar las carpetas en las que se quiera desactivar esa opción de "cacheo masivo" e indiscriminado.
No es cacheo, es que si cada vez que borras lo tiene que borrar de verdad el formato mbox es muy lento (seria borrar y compactar). Asi que solo lo marca para borrar cuando compactes. Opcion : pon compactar si me ahorro 1KB de espacio
Señores, por mi bandeja de entrada (y por la millones de personas) entran correos espantosamente enormes (no es culpa mía que alguien me envíe correos de 20/30/40 MiB). Y cuando borro un mensaje, espero que se vaya a la papelera (ya lo recuperaré de ahí en caso de que lo necesite). Pues no, hala, a eliminar *y a compactar* toca -dos acciones por una, que hay rebajas-, porque no lo puedo desactivar y los mensajes de cachean, sí o sí.
Pero eso es el formato mbox, que a mi me va muy bien asi. Lo que si estoy de acuerdo en que deberia soportar el otro formato
Nota: el correo es sólo una pataleta por el casi /1 GiB/ que he liberado tras empezar a compactar compulsivamente el resto de carpetas.
Saludos,
Pos na desahogate que para eso estamos. Saludillos y Thundercito hasta en la sopa. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Wed, 24 Feb 2010 13:10:59 +0100, francisco f escribió:
On Wednesday 24 February 2010 11:30:40 Camaleón wrote:
Editar-Preferencias-Avanzadas - Red y Espacio en disco habilita compactar cuando ahorres tanto espacio en disco.
Pero es peligroso hacerlo online :-(
¿Por? cuando compacta el thundercito bloquea cualquier otro acceso a los ficheros y hasta que no acaba no puedes hacer nada. Naturalmente si se te cae el ordeñador pos mal vamos, pero aun asi se puede recuperar algo.
Y tengo unos cuantos asi, y nunca ha fallado (joder como falle ahora sus enterareis)
Es peligroso por: a) Posible corrupción de directorios (carpetas) b) Posible pérdida de datos Lo pone en la página de Thunderc... del Palomino, la que envié antes. http://kb.mozillazine.org/Compacting_folders Recomiendan realizar sólo *operaciones de lectura* (ver los correos) cuando se están compactando los mensajes. Lo tienen "re-que-te-documentado" y asimilado (hasta se generan archivos "nstmp" que indican que algo ha ido mal), lo cual es un punto a su favor, pero si lo dicen, por algo será. El correo para mí es sagrado. Tengo documentos y mensajes del año 1.999 :-)
¿Bueno "para quién"? >:-)
Para mi, hay mucho iluminado manazas que borar y borra y borra, luego tienes que hacer milagros para recuperarle el super correo que borro.
Oño, pues para eso está la papelera. Si la han vaciado, pues ajo y agua. Y si quieren recuperar un correo que han eliminado conscientemente, se les dice -sin sobresaltos- que la magia sólo existe en Disneyland® Resort Paris (y sus franquicias).
Arrrhgg, pero eso no tiene sentido alguno, ¡estamos en el año 2010! y / exijo/ cierta eficiencia y automatismo en un cliente de correo :-)
Si lo quieres automatico pues lo pones, que te pregunte o que no.
Automático no me gusta. Manual se va a quedar. He visto que al menos se puedo ejecutar de una sola tacada, compactando todos los directorios. Primero lo pongo en modo "desconectado" y luego lo ejecuto. Pero es *otra tarea más* que tengo que recordar hacer y eso es una p*****.
1/ A día de hoy sea preciso compactar las carpetas
Pues si es por mi no quitaria la funcion.
Hombre, claro, visto que no son capaces de mejorar el formato mbox o de implementar alguna solución intermedia, más flexible, pues claro, qué remedio. Pero eso no quita para que al menos permitieran que el usuario lo personalizara al gusto. La carpeta de la bandeja de entrada, por ejemplo, no puede/debe tener el mismo comportamiento que el resto de carpetas que crea el usuario. Y no lo puede/debe tener porque es una carpeta "especial", no de almacenmaiento: todo el correo pasa por ahí, salvo que se haya configurado una regla que derive el mensaje a otra carpeta. Con lo cual, con este maravilloso sistema del mbox, la bandeja de entrada se convierte en un recolector de basura -> correo que pasa, correo que se almacena -> carpeta que necesita compactarse con asiduidad. Bien, pues los de Thunder... Palomino se han pensado que la gente tiende a tener la bandeja de entrada a tope y han debido de pensar que al usar el sistema de "no borrar el mensaje, sólo marcarlo como borrado" se iba a agilizar la operación de escritura. "Craso error", porque para quien mantiene una bandeja de entrada limpia, con pocos mensajes, le puede resultar factible que las operaciones de borrado se ejecuten en tiempo real y no tener que preocuparse de estar compactando la bandeja de entrada cada poco tiempo. Que es lo que ha generado que teniendo sólo un mensaje de 3 KiB. el archivo inbox pasara a tener 650 MiB. en este caso. Y para más inri, de manera predeterminada no activan la opción de compactar... ¿acaso porque ellos mismos piensan que no es segura y se curan en salud?
2/ A día de hoy la operación de compactación sea peligrosa hacerla online (¿tengo que estar pendiente de qué hago o dejo de hacer porque "el señor cliente de correo" está en una operación de compactado?) >
pos no se que decirte, cuando a mi me compacta bloquea las demas operaciones
No es eso lo que pone en el artículo :-?
3/ No permita seleccionar las carpetas en las que se quiera desactivar esa opción de "cacheo masivo" e indiscriminado.
No es cacheo, es que si cada vez que borras lo tiene que borrar de verdad el formato mbox es muy lento (seria borrar y compactar). Asi que solo lo marca para borrar cuando compactes. Opcion : pon compactar si me ahorro 1KB de espacio
¿Lento? ¿Lento...? ¿Lento borrar en archivo de 3 KiB con un micro de 4 núcleos y 8 GiB de ram? Lento es ir de Madrid a Valencia en burro, qué gaitas >:-) El problema es que ellos _no saben_ cuánto ocupa la bandeja de entrada de los usuarios, ni qué equipo tienen, luego si no lo saben (porque no lo pueden saber) podrían: 1/ Permitir que el usuario lo configure a su gusto. 2/ Incluir alguna rutina de detección del tamaño del directorio que active la necesidad de compactación *sólo* cuando el tamaño de la carpeta sea un factor determinante para ganar velocidad en escritura.
Señores, por mi bandeja de entrada (y por la millones de personas) entran correos espantosamente enormes (no es culpa mía que alguien me envíe correos de 20/30/40 MiB). Y cuando borro un mensaje, espero que se vaya a la papelera (ya lo recuperaré de ahí en caso de que lo necesite). Pues no, hala, a eliminar *y a compactar* toca -dos acciones por una, que hay rebajas-, porque no lo puedo desactivar y los mensajes de cachean, sí o sí.
Pero eso es el formato mbox, que a mi me va muy bien asi. Lo que si estoy de acuerdo en que deberia soportar el otro formato
Después de haber probado las mieles del maildir (Kmail) estas cosas me ponen los pelos de punta. Y parece que no están muy interesados en añadir el soporte de maildir, me parece a mí...
Saludillos y Thundercito hasta en la sopa.
"Dito" Palomino... :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-02-24 a las 14:48 -0000, Camaleón escribió:
La carpeta de la bandeja de entrada, por ejemplo, no puede/debe tener el mismo comportamiento que el resto de carpetas que crea el usuario. Y no lo puede/debe tener porque es una carpeta "especial", no de almacenmaiento: todo el correo pasa por ahí, salvo que se haya configurado una regla que derive el mensaje a otra carpeta. Con lo cual, con este maravilloso sistema del mbox, la bandeja de entrada se convierte en un recolector de basura -> correo que pasa, correo que se almacena -> carpeta que necesita compactarse con asiduidad.
La carpeta de entrada no se pone local, es remota, por lo que no hay que hacer nada. Puede tener copia local sincronizada, pero eso es distinto. O bien, puedes ponerte tu propio servidor imap local y guardar todo el correo allí, así puede estar en maildir si quieres.
No es cacheo, es que si cada vez que borras lo tiene que borrar de verdad el formato mbox es muy lento (seria borrar y compactar). Asi que solo lo marca para borrar cuando compactes. Opcion : pon compactar si me ahorro 1KB de espacio
¿Lento? ¿Lento...? ¿Lento borrar en archivo de 3 KiB con un micro de 4 núcleos y 8 GiB de ram? Lento es ir de Madrid a Valencia en burro, qué gaitas >:-)
Cuando el mbox tiene sólo 3 kb, sí, es rápido. Pero si tiene cientos de correos y unos cuantos por borrar, sí es lento. Ten en cuenta que es un fichero de texto plano, y borrar correos supone en realidad copiar el fichero antiguo en uno nuevo, completo. Es una operación costosa que es preferible hacerla bajo petición o cuando sea necesario. La idea de hacer operaciones costosas porque los ordenadores sean más rápidos es lo que hacen los "malos desarrolladores" que han conseguido que el software sea cada vez más lento, porque piensan que todo el mundo tiene procesadores velocísimos, a los que sobrecargan de trabajo innecesario. Se tiene unos ordenadores 10 veces más rápidos que en realidad trabajan sólo 5 veces más rápidos porque no han diseñado bien el software.
El problema es que ellos _no saben_ cuánto ocupa la bandeja de entrada de los usuarios, ni qué equipo tienen, luego si no lo saben (porque no lo pueden saber) podrían:
1/ Permitir que el usuario lo configure a su gusto.
2/ Incluir alguna rutina de detección del tamaño del directorio que active la necesidad de compactación *sólo* cuando el tamaño de la carpeta sea un factor determinante para ganar velocidad en escritura.
Y de hecho lo tienen. Se dispara por tamaño, estimar la velocidad no se puede estimar a priori.
Pero eso es el formato mbox, que a mi me va muy bien asi. Lo que si estoy de acuerdo en que deberia soportar el otro formato
Después de haber probado las mieles del maildir (Kmail) estas cosas me ponen los pelos de punta. Y parece que no están muy interesados en añadir el soporte de maildir, me parece a mí...
Iría fatal en los thundercitos bajo windows. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkuFmRoACgkQtTMYHG2NR9X0jACdFs7ypo5Nk1xDeuWJ9MCHTvHs LyEAn34DmNaMjG2Vgtme2l/KwYNYTk15 =ziPo -----END PGP SIGNATURE-----
El Wed, 24 Feb 2010 22:24:34 +0100, Carlos E. R. escribió:
El 2010-02-24 a las 14:48 -0000, Camaleón escribió:
La carpeta de la bandeja de entrada, por ejemplo, no puede/debe tener el mismo comportamiento que el resto de carpetas que crea el usuario. Y no lo puede/debe tener porque es una carpeta "especial", no de almacenmaiento: todo el correo pasa por ahí, salvo que se haya configurado una regla que derive el mensaje a otra carpeta. Con lo cual, con este maravilloso sistema del mbox, la bandeja de entrada se convierte en un recolector de basura -> correo que pasa, correo que se almacena -> carpeta que necesita compactarse con asiduidad.
La carpeta de entrada no se pone local, es remota, por lo que no hay que hacer nada. Puede tener copia local sincronizada, pero eso es distinto.
Mi inbox es local. De hecho todos las carpetas son locales, salvo las de las cuentas imap.
O bien, puedes ponerte tu propio servidor imap local y guardar todo el correo allí, así puede estar en maildir si quieres.
¿Y? El Thunderc... el Palomino lo pasa a mbox (en local) → chapuza >:-)
¿Lento? ¿Lento...? ¿Lento borrar en archivo de 3 KiB con un micro de 4 núcleos y 8 GiB de ram? Lento es ir de Madrid a Valencia en burro, qué gaitas >:-)
Cuando el mbox tiene sólo 3 kb, sí, es rápido.
Mi mbox _tenía_ 3 KiB. El Palomino metió la gamba (no configuró las opciones adecuadas para evitar la catástrofe) y la aumentó a 650 MiB. Y sin avisar ni "ná".
Pero si tiene cientos de correos y unos cuantos por borrar, sí es lento.
Pero eso tendrá que decidirlo el usuario, no el Palomino. Sólo el usuario puede saber si sus carpetas tienen (o van a tener) 1 o 10.000 correos. Y no se puede tratar de igual forma una carpeta con 1 que con 10.000 archivos.
Ten en cuenta que es un fichero de texto plano, y borrar correos supone en realidad copiar el fichero antiguo en uno nuevo, completo. Es una operación costosa que es preferible hacerla bajo petición o cuando sea necesario.
No, si la teoría ya la he leído, además de que la explica muy bien el Palomino en su página de "excusa", quiero decir, en la FAQ.
La idea de hacer operaciones costosas porque los ordenadores sean más rápidos es lo que hacen los "malos desarrolladores" que han conseguido que el software sea cada vez más lento, porque piensan que todo el mundo tiene procesadores velocísimos, a los que sobrecargan de trabajo innecesario. Se tiene unos ordenadores 10 veces más rápidos que en realidad trabajan sólo 5 veces más rápidos porque no han diseñado bien el software.
No, la idea es hacer las *operaciones lógicas* que permitan obtener el mejor ratio de rendimiento posible, y no veo ninguna lógica en almacenar 650 MiB "ocultos" en la bandeja de entrada y en forzar al usuario a realizar un mantenimiento continuado en el cliente de correo. Ni el "Outlooks 2000" hace eso, oiga. A los 4 GiB, ya no se vuelve a abrir y santas pascuas O:-P
El problema es que ellos _no saben_ cuánto ocupa la bandeja de entrada de los usuarios, ni qué equipo tienen, luego si no lo saben (porque no lo pueden saber) podrían:
1/ Permitir que el usuario lo configure a su gusto.
2/ Incluir alguna rutina de detección del tamaño del directorio que active la necesidad de compactación *sólo* cuando el tamaño de la carpeta sea un factor determinante para ganar velocidad en escritura.
Y de hecho lo tienen. Se dispara por tamaño, estimar la velocidad no se puede estimar a priori.
Y un cuerno. En primer lugar *se almacenan* los datos de manera indiscriminada (sin límite, hasta que hubiera dejado la carpeta inservible, supongo...). Ese es el primer error. En segundo lugar, no permiten configurar ese comportamiento, con lo cual tienes que compactar continuamente la bandeja de entrada, en cualquier caso, para evitar un desastre.
Después de haber probado las mieles del maildir (Kmail) estas cosas me ponen los pelos de punta. Y parece que no están muy interesados en añadir el soporte de maildir, me parece a mí...
Iría fatal en los thundercitos bajo windows.
¿Por...? ¿Acaso tienes datos del rendimiento del NTFS con archivos pequeños? :-? Yo creo que no lo quieren hacer porque el Palomino estará diseñado de forma totalmente dependiente respecto a ese formato. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-02-24 a las 23:23 -0000, Camaleón escribió:
El Wed, 24 Feb 2010 22:24:34 +0100, Carlos E. R. escribió:
O bien, puedes ponerte tu propio servidor imap local y guardar todo el correo allí, así puede estar en maildir si quieres.
¿Y? El Thunderc... el Palomino lo pasa a mbox (en local) → chapuza >:-)
No lo pasa si no le dices que mantenga copia sincronizada, usará siempre el almacenamiento remoto - que en realidad es local también, tu propio servidor imap local. Puedes así tener todas tus carpetas en el servidor imap local en maildir.
¿Lento? ¿Lento...? ¿Lento borrar en archivo de 3 KiB con un micro de 4 núcleos y 8 GiB de ram? Lento es ir de Madrid a Valencia en burro, qué gaitas >:-)
Cuando el mbox tiene sólo 3 kb, sí, es rápido.
Mi mbox _tenía_ 3 KiB. El Palomino metió la gamba (no configuró las opciones adecuadas para evitar la catástrofe) y la aumentó a 650 MiB. Y sin avisar ni "ná".
No, tenía 650 MiB de los cuales sólo 3 KiB eran activos. El resto serían correos borrados.
Pero si tiene cientos de correos y unos cuantos por borrar, sí es lento.
Pero eso tendrá que decidirlo el usuario, no el Palomino. Sólo el usuario puede saber si sus carpetas tienen (o van a tener) 1 o 10.000 correos. Y no se puede tratar de igual forma una carpeta con 1 que con 10.000 archivos.
Claro que se puede y se hace >:-) Se trabaja con la suposición de va a tener muchos correos. Si tiene menos, pues mejor.
La idea de hacer operaciones costosas porque los ordenadores sean más rápidos es lo que hacen los "malos desarrolladores" que han conseguido que el software sea cada vez más lento, porque piensan que todo el mundo tiene procesadores velocísimos, a los que sobrecargan de trabajo innecesario. Se tiene unos ordenadores 10 veces más rápidos que en realidad trabajan sólo 5 veces más rápidos porque no han diseñado bien el software.
No, la idea es hacer las *operaciones lógicas* que permitan obtener el mejor ratio de rendimiento posible, y no veo ninguna lógica en almacenar 650 MiB "ocultos" en la bandeja de entrada y en forzar al usuario a realizar un mantenimiento continuado en el cliente de correo.
Claro que tiene lógica. Lo que no tiene lógica es que el Thunderbird no sea capaz de gestionarlo sin cagarla. Otros lo hacen.
Ni el "Outlooks 2000" hace eso, oiga. A los 4 GiB, ya no se vuelve a abrir y santas pascuas O:-P
Luego usa un sistema parecido, y peor hecho.
El problema es que ellos _no saben_ cuánto ocupa la bandeja de entrada de los usuarios, ni qué equipo tienen, luego si no lo saben (porque no lo pueden saber) podrían:
1/ Permitir que el usuario lo configure a su gusto.
2/ Incluir alguna rutina de detección del tamaño del directorio que active la necesidad de compactación *sólo* cuando el tamaño de la carpeta sea un factor determinante para ganar velocidad en escritura.
Y de hecho lo tienen. Se dispara por tamaño, estimar la velocidad no se puede estimar a priori.
Y un cuerno.
En primer lugar *se almacenan* los datos de manera indiscriminada (sin límite, hasta que hubiera dejado la carpeta inservible, supongo...). Ese es el primer error.
Culpa tuya por no dejar que la compacte automáticamente >:-P
En segundo lugar, no permiten configurar ese comportamiento, con lo cual tienes que compactar continuamente la bandeja de entrada, en cualquier caso, para evitar un desastre.
¿Continuamente? No que va, de vez en cuando.
Después de haber probado las mieles del maildir (Kmail) estas cosas me ponen los pelos de punta. Y parece que no están muy interesados en añadir el soporte de maildir, me parece a mí...
Iría fatal en los thundercitos bajo windows.
¿Por...? ¿Acaso tienes datos del rendimiento del NTFS con archivos pequeños? :-? Yo creo que no lo quieren hacer porque el Palomino estará diseñado de forma totalmente dependiente respecto a ese formato.
No todos los windows usan ntfs, muchos usan fat. Y con fat te garantizo que va horrible. Y no, no voy a hacer un benchmark en mi windosito con ntfs para ver como se porta con 8000 ficheros en un sólo directorio, no sea que pete y me toque reinstalarlo :-P De todos modos, lo de siempre: es software libre, puedes ponerte e implementarle las adiciones para que soporte Maildir - lo mismo que alguien hizo con Pine >:-P - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkuFyO0ACgkQtTMYHG2NR9UTwQCfXJEWFgPIaBtbt0iA+76bR52g 86UAoJbmYFka4wpnvbXU85iHJuOqEjpH =KLDv -----END PGP SIGNATURE-----
El Thu, 25 Feb 2010 01:48:43 +0100, Carlos E. R. escribió:
El 2010-02-24 a las 23:23 -0000, Camaleón escribió:
Cuando el mbox tiene sólo 3 kb, sí, es rápido.
Mi mbox _tenía_ 3 KiB. El Palomino metió la gamba (no configuró las opciones adecuadas para evitar la catástrofe) y la aumentó a 650 MiB. Y sin avisar ni "ná".
No, tenía 650 MiB de los cuales sólo 3 KiB eran activos. El resto serían correos borrados.
Pues eso... "correos borrados" significa "correos borrados" no "correos ocultados" :-)
No, la idea es hacer las *operaciones lógicas* que permitan obtener el mejor ratio de rendimiento posible, y no veo ninguna lógica en almacenar 650 MiB "ocultos" en la bandeja de entrada y en forzar al usuario a realizar un mantenimiento continuado en el cliente de correo.
Claro que tiene lógica. Lo que no tiene lógica es que el Thunderbird no sea capaz de gestionarlo sin cagarla. Otros lo hacen.
¿Dónde ves la lógica en almacenar todo lo que le pasa por la bandeja de entrada? Si el resto de programas utilizaran la misma /lógica/ no tendríamos espacio en disco suficiente ni para un día >:-)
En primer lugar *se almacenan* los datos de manera indiscriminada (sin límite, hasta que hubiera dejado la carpeta inservible, supongo...). Ese es el primer error.
Culpa tuya por no dejar que la compacte automáticamente >:-P
No es la opción predeterminada. Y que no lo hayan activado de manera predeterminada no me da mucha confianza, la verdad.
En segundo lugar, no permiten configurar ese comportamiento, con lo cual tienes que compactar continuamente la bandeja de entrada, en cualquier caso, para evitar un desastre.
¿Continuamente? No que va, de vez en cuando.
Eso dependerá de cada usuario. Echa cuentas: en 4 meses -> 650 MiB (sólo en el inbox).
Iría fatal en los thundercitos bajo windows.
¿Por...? ¿Acaso tienes datos del rendimiento del NTFS con archivos pequeños? :-? Yo creo que no lo quieren hacer porque el Palomino estará diseñado de forma totalmente dependiente respecto a ese formato.
No todos los windows usan ntfs, muchos usan fat. Y con fat te garantizo que va horrible.
¿FAT32? Ya no... no al menos desde el windows 2000/xp (y de eso hace 10 años). Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 2010-02-25 08:48, Camaleón wrote:
El Thu, 25 Feb 2010 01:48:43 +0100, Carlos E. R. escribió:
El 2010-02-24 a las 23:23 -0000, Camaleón escribió:
Cuando el mbox tiene sólo 3 kb, sí, es rápido.
Mi mbox _tenía_ 3 KiB. El Palomino metió la gamba (no configuró las opciones adecuadas para evitar la catástrofe) y la aumentó a 650 MiB. Y sin avisar ni "ná".
No, tenía 650 MiB de los cuales sólo 3 KiB eran activos. El resto serían correos borrados.
Pues eso... "correos borrados" significa "correos borrados" no "correos ocultados" :-)
De cara al usuario, son borrados.
No, la idea es hacer las *operaciones lógicas* que permitan obtener el mejor ratio de rendimiento posible, y no veo ninguna lógica en almacenar 650 MiB "ocultos" en la bandeja de entrada y en forzar al usuario a realizar un mantenimiento continuado en el cliente de correo.
Claro que tiene lógica. Lo que no tiene lógica es que el Thunderbird no sea capaz de gestionarlo sin cagarla. Otros lo hacen.
¿Dónde ves la lógica en almacenar todo lo que le pasa por la bandeja de entrada? Si el resto de programas utilizaran la misma /lógica/ no tendríamos espacio en disco suficiente ni para un día >:-)
Pero es que, aunque no te lo creas, muchos programas usan la misma técnica. Se ha usado desde el principio y se sigue usando, porque es útil. Lo usan hasta los sistemas de ficheros, incluidos el extX o el FAT: lo que se borra se marca como borrado, no de borra de hecho.
En primer lugar *se almacenan* los datos de manera indiscriminada (sin límite, hasta que hubiera dejado la carpeta inservible, supongo...). Ese es el primer error.
Culpa tuya por no dejar que la compacte automáticamente >:-P
No es la opción predeterminada. Y que no lo hayan activado de manera predeterminada no me da mucha confianza, la verdad.
Porque no lo han implementado bien. Ya te lo he dicho muchas veces.
En segundo lugar, no permiten configurar ese comportamiento, con lo cual tienes que compactar continuamente la bandeja de entrada, en cualquier caso, para evitar un desastre.
¿Continuamente? No que va, de vez en cuando.
Eso dependerá de cada usuario.
Echa cuentas: en 4 meses -> 650 MiB (sólo en el inbox).
No, el usuario no tiene normalmente base para tomar esas decisiones. ¿No has compactado en cuatro meses? Ya os vale. :-p
Iría fatal en los thundercitos bajo windows.
¿Por...? ¿Acaso tienes datos del rendimiento del NTFS con archivos pequeños? :-? Yo creo que no lo quieren hacer porque el Palomino estará diseñado de forma totalmente dependiente respecto a ese formato.
No todos los windows usan ntfs, muchos usan fat. Y con fat te garantizo que va horrible.
¿FAT32? Ya no... no al menos desde el windows 2000/xp (y de eso hace 10 años).
No creas, conozco gente que lo sigue instalando con fat. -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Thu, 25 Feb 2010 17:17:34 +0100, Carlos E.R. escribió:
On 2010-02-25 08:48, Camaleón wrote:
Pues eso... "correos borrados" significa "correos borrados" no "correos ocultados" :-)
De cara al usuario, son borrados.
Es información "falsa" luego es información "inútil".
¿Dónde ves la lógica en almacenar todo lo que le pasa por la bandeja de entrada? Si el resto de programas utilizaran la misma /lógica/ no tendríamos espacio en disco suficiente ni para un día >:-)
Pero es que, aunque no te lo creas, muchos programas usan la misma técnica. Se ha usado desde el principio y se sigue usando, porque es útil. Lo usan hasta los sistemas de ficheros, incluidos el extX o el FAT: lo que se borra se marca como borrado, no de borra de hecho.
Carlos, que los de Mozilla saben lo que tienen entre manos y saben las limitaciones intrínsecas del mbox, aunque tú no lo creas. Y no, ningún programa mantiene los datos eliminados en el disco duro de manera continuada y permite que le estalle al usuario (es decir, que se le llegue a corromper el archivo). Cuando eso sucede, se le llama "bug", se marca como "crítico" y se corrige >:-) Por cierto, hasta el fat te pregunta *si quieres eliminar los mensajes de la papelera" en las unidades USB. Vaya, que *te avisa*.
Culpa tuya por no dejar que la compacte automáticamente >:-P
No es la opción predeterminada. Y que no lo hayan activado de manera predeterminada no me da mucha confianza, la verdad.
Porque no lo han implementado bien. Ya te lo he dicho muchas veces.
"Chapuza" es el adjetivo que he empleado si mal no recuerdo. Y "limitado" es el adjetivo que he empleado para el mbox.
¿Continuamente? No que va, de vez en cuando.
Eso dependerá de cada usuario.
Echa cuentas: en 4 meses -> 650 MiB (sólo en el inbox).
No, el usuario no tiene normalmente base para tomar esas decisiones.
¿No has compactado en cuatro meses? Ya os vale. :-p
¿"Os"? ¿A quiénes te refieres? :-? En la oficina sólo yo uso /cosas raras/ como KMail o el Palomino... el resto usa programas "normales" como el Outlook (2000-2007) :-P
No todos los windows usan ntfs, muchos usan fat. Y con fat te garantizo que va horrible.
¿FAT32? Ya no... no al menos desde el windows 2000/xp (y de eso hace 10 años).
No creas, conozco gente que lo sigue instalando con fat.
Pues que usen el formato de almacenamiento que prefieran. La gente con sistemas de archivos modernos queremos "maildir" :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 2010-02-25 17:50, Camaleón wrote:
El Thu, 25 Feb 2010 17:17:34 +0100, Carlos E.R. escribió:
On 2010-02-25 08:48, Camaleón wrote:
Pues eso... "correos borrados" significa "correos borrados" no "correos ocultados" :-)
De cara al usuario, son borrados.
Es información "falsa" luego es información "inútil".
Para el usuario, para el sistema no.
¿Dónde ves la lógica en almacenar todo lo que le pasa por la bandeja de entrada? Si el resto de programas utilizaran la misma /lógica/ no tendríamos espacio en disco suficiente ni para un día >:-)look revienta cuando llega a cuatro gigas.
Pero es que, aunque no te lo creas, muchos programas usan la misma técnica. Se ha usado desde el principio y se sigue usando, porque es útil. Lo usan hasta los sistemas de ficheros, incluidos el extX o el FAT: lo que se borra se marca como borrado, no de borra de hecho.
Carlos, que los de Mozilla saben lo que tienen entre manos y saben las limitaciones intrínsecas del mbox, aunque tú no lo creas.
¡Faltaría menos que no lo supieran!
Y no, ningún programa mantiene los datos eliminados en el disco duro de manera continuada
¡Vaya que no!
y permite que le estalle al usuario (es decir, que se le llegue a corromper el archivo). Cuando eso sucede, se le llama "bug", se marca como "crítico" y se corrige >:-)
Claro, no estalla porque lo han hecho bien, No todos, el outlook/exchange estalla cuando llega a cuatro gigas. También él necesita compactar manualmente.
Por cierto, hasta el fat te pregunta *si quieres eliminar los mensajes de la papelera" en las unidades USB. Vaya, que *te avisa*.
No hablo de la papelera para nada. Incluso cuando lo borras de la papelera el fichero sigue ahí, marcado como borrado. Ya no lo puedes recuperar salvo con herramientas especiales si nadie ha escrito encima, porque se puede hacer eso, escibir encima de lo borrado en muchos de los programas que usan ese sistema.
¿No has compactado en cuatro meses? Ya os vale. :-p
¿"Os"? ¿A quiénes te refieres? :-?
A tí y al truenecito.
En la oficina sólo yo uso /cosas raras/ como KMail o el Palomino... el resto usa programas "normales" como el Outlook (2000-2007) :-P
espero que ese outlook haya corregido el problema del cuelgue irrecuperable a los cuatro gigas >:-)
No todos los windows usan ntfs, muchos usan fat. Y con fat te garantizo que va horrible.
¿FAT32? Ya no... no al menos desde el windows 2000/xp (y de eso hace 10 años).
No creas, conozco gente que lo sigue instalando con fat.
Pues que usen el formato de almacenamiento que prefieran. La gente con sistemas de archivos modernos queremos "maildir" :-)
¿Has probado maildir con 10000 correos en la misma carpeta, sin usar reiserfs? ¿Has probado entonces a hacer una búsqueda textual? Yo no quiero maildir ni en pintura. -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Thu, 25 Feb 2010 20:13:21 +0100, Carlos E.R. escribió:
On 2010-02-25 17:50, Camaleón wrote:
Es información "falsa" luego es información "inútil".
Para el usuario, para el sistema no.
No, claro. Y precisamente por eso se corrompen los mbox gigantestos "para el sistema".
Carlos, que los de Mozilla saben lo que tienen entre manos y saben las limitaciones intrínsecas del mbox, aunque tú no lo creas.
¡Faltaría menos que no lo supieran!
Y no lo solucionan... qué bonito.
Y no, ningún programa mantiene los datos eliminados en el disco duro de manera continuada
¡Vaya que no!
Ninguno. ¿Cuántos años tiene el disco duro donde tienes la 11.1? ¿Te sigue funcionando, se te ha agotado el espacio, se puede iniciar, se han corrompido los archivos? ¿verdad que no? Eso es porque el sistema de archivos "sabe" cómo gestionarlo. El Palomino no se entera, si por él fuera, hubiera seguido aumentando el archivo de la bandeja de entrada hasta reventar el espacio en disco.
y permite que le estalle al usuario (es decir, que se le llegue a corromper el archivo). Cuando eso sucede, se le llama "bug", se marca como "crítico" y se corrige >:-)
Claro, no estalla porque lo han hecho bien, No todos, el outlook/exchange estalla cuando llega a cuatro gigas. También él necesita compactar manualmente.
No. El Outlook estalla a los 2 GiB (no a los 4 GiB, como dije antes) "por diseño" no por "falta de compactación". Yo nunca he compactado en Outlook y el archivo *.pst lo dejé con 1,5 GiB de tamaño.
Por cierto, hasta el fat te pregunta *si quieres eliminar los mensajes de la papelera" en las unidades USB. Vaya, que *te avisa*.
No hablo de la papelera para nada. Incluso cuando lo borras de la papelera el fichero sigue ahí, marcado como borrado. Ya no lo puedes recuperar salvo con herramientas especiales si nadie ha escrito encima, porque se puede hacer eso, escibir encima de lo borrado en muchos de los programas que usan ese sistema.
No me refiero a eso. Me refiero a que cuando pinchas una llave USB y eliminas archivos en la llave, se quedan en la papelera de la llave, y al desmontarla/ desconectarla te dice si quieres vaciar la papelera. Los archivos "no son visibles" para el usuario, igual que sucede con el mbox pero al menos te avisa de que aún siguen disponibles.
¿No has compactado en cuatro meses? Ya os vale. :-p
¿"Os"? ¿A quiénes te refieres? :-?
A tí y al truenecito.
Él no estaba preparado para hacerlo. Yo desconocía la *odienda el mbox.
En la oficina sólo yo uso /cosas raras/ como KMail o el Palomino... el resto usa programas "normales" como el Outlook (2000-2007) :-P
espero que ese outlook haya corregido el problema del cuelgue irrecuperable a los cuatro gigas >:-)
El límite ahora es de 20 GiB :-)
No creas, conozco gente que lo sigue instalando con fat.
Pues que usen el formato de almacenamiento que prefieran. La gente con sistemas de archivos modernos queremos "maildir" :-)
¿Has probado maildir con 10000 correos en la misma carpeta, sin usar reiserfs? ¿Has probado entonces a hacer una búsqueda textual?
He probado el maildir y me ha funcionado sin problemas. A mí y a millones de personas (desarrolladores, usuarios, programadores y amas de casa...).
Yo no quiero maildir ni en pintura.
Ni yo quiero el mbox, menuda tortura. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El Thu, 25 Feb 2010 20:13:21 +0100, Carlos E.R. escribió:
Y no, ningún programa mantiene los datos eliminados en el disco duro de manera continuada
¡Vaya que no!
Ninguno.
Muchos. Me podría apostar el sueldo de un mes, si yo apostara. Lo que pasa es que la mayoría lo han implementado bien y no te enteras. Un ejemplo: Alpine con mbox. Tengo carpetas desde el año 95 o por ahí, y ningún problema de compactación. Otros tipos de programas que usan registros marcados como borrados sin borrarlos: la mayoría de los motores de bases de datos, desde dbf hasta los actuales. Los sistemas de ficheros, desde fat hasta ext4. Y no hablo para nada de la papelera, no tiene que ver. Sin papelera.
¿Cuántos años tiene el disco duro donde tienes la 11.1? ¿Te sigue funcionando, se te ha agotado el espacio, se puede iniciar, se han corrompido los archivos? ¿verdad que no? Eso es porque el sistema de archivos "sabe" cómo gestionarlo. El Palomino no se entera, si por él fuera, hubiera seguido aumentando el archivo de la bandeja de entrada hasta reventar el espacio en disco.
Bueno, eso ya lo he dicho desde el principio, han hecho una mala implementación de un buen sistema.
y permite que le estalle al usuario (es decir, que se le llegue a corromper el archivo). Cuando eso sucede, se le llama "bug", se marca como "crítico" y se corrige >:-)
Claro, no estalla porque lo han hecho bien, No todos, el outlook/exchange estalla cuando llega a cuatro gigas. También él necesita compactar manualmente.
No. El Outlook estalla a los 2 GiB (no a los 4 GiB, como dije antes) "por diseño" no por "falta de compactación". Yo nunca he compactado en Outlook y el archivo *.pst lo dejé con 1,5 GiB de tamaño.
También hace compactación. Antiguamente se podía hacer manualmente, había un procedimiento. El límite de 2 gigas es por usar fat.
Por cierto, hasta el fat te pregunta *si quieres eliminar los mensajes de la papelera" en las unidades USB. Vaya, que *te avisa*.
No hablo de la papelera para nada. Incluso cuando lo borras de la papelera el fichero sigue ahí, marcado como borrado. Ya no lo puedes recuperar salvo con herramientas especiales si nadie ha escrito encima, porque se puede hacer eso, escibir encima de lo borrado en muchos de los programas que usan ese sistema.
No me refiero a eso.
Me refiero a que cuando pinchas una llave USB y eliminas archivos en la llave, se quedan en la papelera de la llave, y al desmontarla/ desconectarla te dice si quieres vaciar la papelera. Los archivos "no son visibles" para el usuario, igual que sucede con el mbox pero al menos te avisa de que aún siguen disponibles.
Insisto en que no hablo para nada de la papelera, eso no tiene que ver con este tema. Cuando tu borras físicamente un fichero cualquiera, y no existe papelera, o sea, cuando borras permanentement un fichero, lo que se hace es en la tabla de directorios donde estaba el fichero cambiar la primera letra del nombre por un churruguito (ascii E5), y en cada campo de la FAT de cada cluster usado se escribe un 0 para marcarlo como libre. Pero el fichero sigue estando, la operación es reversible (si se hace a tiempo). En ext2/3/4 se usa un sistema equivalente; el midnight comander es capaz de desborrar ficheros borrados en ext2. En ext3 no se puede por culpa del journal. En la práctica, en un ordenador moderno, es muy dificil desborrar un fichero borrado "permanentemente", porque su espacio puede ser inmediatamente usado por otro proceso. Por eso inventaron lo de la papelera. Cuando un programa libera un trozo de memoria RAM que tenía usado, esa memoria queda usable, pero no se borra. Sigue ahí. Se le puede devolver al sistema, o la puedes reutilizar, en todo o en parte, para otra variable. Algunos lenguajes guardan una lista de memoria "borrada" para su uso posterior. Al cabo del uso la memoria parece un queso de gruyere con trozos de memoria libre que no se puede utilizar. El resultado es que el programa reporta un uso de memoria tremendo, cuando en realidad usa mucho menos. Y no se puede compactar (salvo que los diseñadores del compilador o sistema operativo lo hayan previsto). El mozilla en linux sufre mucho por culpa de esto. El marcar las zonas borradas como borradas, sin borrarlas realmente, es una técnica clásica de programación que se usa continuamente.
En la oficina sólo yo uso /cosas raras/ como KMail o el Palomino... el resto usa programas "normales" como el Outlook (2000-2007) :-P
espero que ese outlook haya corregido el problema del cuelgue irrecuperable a los cuatro gigas >:-)
El límite ahora es de 20 GiB :-)
Porque usais ntfs.
No creas, conozco gente que lo sigue instalando con fat.
Pues que usen el formato de almacenamiento que prefieran. La gente con sistemas de archivos modernos queremos "maildir" :-)
¿Has probado maildir con 10000 correos en la misma carpeta, sin usar reiserfs? ¿Has probado entonces a hacer una búsqueda textual?
He probado el maildir y me ha funcionado sin problemas. A mí y a millones de personas (desarrolladores, usuarios, programadores y amas de casa...).
Nativa y preferentemente sólo lo usa el kmail como MUA. Otros lo admiten con un parche. En la wikipedia tienes la lista. No son tantos. Por cierto, que ya te dije cual es el truco para usar maildir como Th... ¿No lo viste? No has comentado sobre ello. Mira, copio lo que opinó Mark Crispin, el inventor del imap, y uno de los programadores principales del Pine, sobre maildir (ya lo puse hace un año): +++··········································· Date: Fri Jan 5 23:43:47 2007 From: Mark Crispin <> Subject: [Alpine-alpha] Maildir support On Sat, 6 Jan 2007, Asheesh Laroia wrote:
Joey Hess filed a bug in the Debian package (*) about Alpine lacking support for the Maildir mail storage format. Apparently the pine source package that Debian ships comes with a patch for Maildir support.
Apparently, it comes with an unsupported third-party maildir driver for the c-client library.
Do you guys (washington.edu) plan to add Maildir support to Alpine?
I (the c-client library developer) do not have any such plans. Sadly, the maildir church claims that I don't do maildir out of some evil intent. Here are the facts: I do not know how to make a maildir driver that works well, which I define as: . complete compliance with IMAP's specifications . complete compliance with DSB's specifications . satisfactory performance I know how to do two of these, but not all three simultaneously. I refuse to have my name associated with IMAP non-compliance. DSB would flame me to a crisp if I don't comply with his maildir specifications. That leaves lousy performance, and I would be flamed for "deliberately making it because [I] dislike maildir." It's a no-win situation for me.
From what I have seen of the third-party maildir drivers, they cut corners on all three. Some also have a negative impact on non-maildir usage.
I've fielded numerous Pine/c-client bug reports which turned out to be caused by these maildir drivers. When it turns out that the user does not use maildir, I recommend that s/he replace whatever distribution with an unmodified UW distribution (which of course has the effect of deleting any other third-party customizations). Similar corner-cutting is done by the IMAP servers that support maildir. For example, Courier actually implements something that it calls maildir++ and a heresy of IMAP that it calls SMAP instead of true maildir and IMAP. The difficulty is that IMAP and maildir have some seriously conflicting requirements. Neither one considered the other when it was designed, and it shows.
If not, has anyone in the community considered writing such a patch for Alpine?
I'm sure that the third-parties which provide maildir drivers for older versions of the c-client library have (or will soon have) updated versions that fit in the imap-2006 version that is used by Alpine. Please be assured that if I had a brainstorm and suddenly realized how to write a maildir driver that works well (as defined above), I would do so. I haven't had such a brainstorm, and apparently nobody else has either. - -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ++-··········································· http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg288744.html
Yo no quiero maildir ni en pintura.
Ni yo quiero el mbox, menuda tortura.
No lo has probado en una buena implementación. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkuG73MACgkQtTMYHG2NR9X/6wCeKBywwwXi0yCH7YIh2ZOpS82P 8bQAn31z85CpjS8w4rWu/yHaEPRm+Wv2 =x2Bz -----END PGP SIGNATURE-----
El Thu, 25 Feb 2010 22:45:16 +0100, Carlos E. R. escribió:
El 2010-02-25 a las 19:38 -0000, Camaleón escribió:
Y no, ningún programa mantiene los datos eliminados en el disco duro de manera continuada
¡Vaya que no!
Ninguno.
Muchos. Me podría apostar el sueldo de un mes, si yo apostara. Lo que pasa es que la mayoría lo han implementado bien y no te enteras.
Imposible. Lo que tú dices no es "mantener los datos eliminados de manera continuada" ya que se sobreescriben automáticamente y por tanto, los pierdes. Eso no puede pasar con el correo, por ejemplo, o cuando necesitas un archivado permanente.
Un ejemplo: Alpine con mbox. Tengo carpetas desde el año 95 o por ahí, y ningún problema de compactación.
No hablamos de eso.
¿Cuántos años tiene el disco duro donde tienes la 11.1? ¿Te sigue funcionando, se te ha agotado el espacio, se puede iniciar, se han corrompido los archivos? ¿verdad que no? Eso es porque el sistema de archivos "sabe" cómo gestionarlo. El Palomino no se entera, si por él fuera, hubiera seguido aumentando el archivo de la bandeja de entrada hasta reventar el espacio en disco.
Bueno, eso ya lo he dicho desde el principio, han hecho una mala implementación de un buen sistema.
Sistema mediocre + pésima implementación = problemas.
y permite que le estalle al usuario (es decir, que se le llegue a corromper el archivo). Cuando eso sucede, se le llama "bug", se marca como "crítico" y se corrige >:-)
Claro, no estalla porque lo han hecho bien, No todos, el outlook/exchange estalla cuando llega a cuatro gigas. También él necesita compactar manualmente.
No. El Outlook estalla a los 2 GiB (no a los 4 GiB, como dije antes) "por diseño" no por "falta de compactación". Yo nunca he compactado en Outlook y el archivo *.pst lo dejé con 1,5 GiB de tamaño.
También hace compactación. Antiguamente se podía hacer manualmente, había un procedimiento.
Totalmente opcional, como te he dicho.
El límite de 2 gigas es por usar fat.
No. *** http://support.microsoft.com/kb/830336 Los archivos de carpetas personales (.pst) de Microsoft Office Outlook 2007 y de Microsoft Office Outlook 2003 tienen un formato diferente y un mayor límite de tamaño de carpeta que en versiones anteriores de Microsoft Outlook. En Outlook 2002 y versiones anteriores, los archivos .pst tenían formato ANSI (American National Standards Institute) y un tamaño total de 2 gigabytes (GB). *** Nada que ver con tener el sistema de archivos en FAT, que además de que éste admite hasta 4 GiB/archivo.
espero que ese outlook haya corregido el problema del cuelgue irrecuperable a los cuatro gigas >:-)
El límite ahora es de 20 GiB :-)
Porque usais ntfs.
Je, siempre hemos usado ntfs en windows xp y la limitación del outlook 2000 seguía existiendo. Que no, que no es eso :-)
¿Has probado maildir con 10000 correos en la misma carpeta, sin usar reiserfs? ¿Has probado entonces a hacer una búsqueda textual?
He probado el maildir y me ha funcionado sin problemas. A mí y a millones de personas (desarrolladores, usuarios, programadores y amas de casa...).
Nativa y preferentemente sólo lo usa el kmail como MUA. Otros lo admiten con un parche. En la wikipedia tienes la lista. No son tantos.
Es un sistema más moderno. No todos los proyectos tienen recursos para implementarlo (si Mozilla tiene tantos problemas, imagínate el resto...), como los de Alpine que a punto están -si no lo han hecho ya- de dejar el desarrollo de su cliente de correo >:-) Windows Mail y Mail, clientes de correo predeterminados de las nuevas versiones de Windows y MacOS, respectivamente, utilizan la misma estrategia de almacenamiento de maildir: un archivo por correo.
Por cierto, que ya te dije cual es el truco para usar maildir como Th... ¿No lo viste? No has comentado sobre ello.
Lo siento pero no. Tener el correo en la nube (imap), aunque tenga la nube a pocos metros, no me convence. Lo necesito en local.
Mira, copio lo que opinó Mark Crispin, el inventor del imap, y uno de los programadores principales del Pine, sobre maildir (ya lo puse hace un año):
(...) Que ya lo sé... que las opiniones personales me parecen perfectas, para eso están. (...)
<http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/ msg288744.html>
Eso suena a típica excusa de desarrollador para no hacer su trabajo porque requeriría tiempo y esfuerzo extra y sencillamente no está por la labor >:-)
Yo no quiero maildir ni en pintura.
Ni yo quiero el mbox, menuda tortura.
No lo has probado en una buena implementación.
En KMail es opcional (salvo que seas de la opinión que KMail también lo implementa "malamente") y no se me pasó por la cabeza usarlo. Desde mi punto de vista, un correo por archivo me parece un sistema mucho más fiable y eficiente. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Viernes, 26 de Febrero de 2010 08:35:57 Camaleón escribió:
En Outlook 2002 y versiones anteriores, los archivos .pst tenían formato ANSI (American National Standards Institute)
Y eso que quiere decir?? es mejor el formato ISO que el ANSI o el ITU :-P Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Fri, 26 Feb 2010 09:30:20 +0100, Angel escribió:
On Viernes, 26 de Febrero de 2010 08:35:57 Camaleón escribió:
En Outlook 2002 y versiones anteriores, los archivos .pst tenían formato ANSI (American National Standards Institute)
Y eso que quiere decir??
Que si usas esa especificación para los archivos pst estás *odido, quiero decir, limitado a un tamaño de archivo concreto.
es mejor el formato ISO que el ANSI o el ITU :-P
Pues parece que es mejor el Unicode :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-02-26 08:35, Camaleón wrote:
El Thu, 25 Feb 2010 22:45:16 +0100, Carlos E. R. escribió:
El 2010-02-25 a las 19:38 -0000, Camaleón escribió:
Y no, ningún programa mantiene los datos eliminados en el disco duro de manera continuada
¡Vaya que no!
Ninguno.
Muchos. Me podría apostar el sueldo de un mes, si yo apostara. Lo que pasa es que la mayoría lo han implementado bien y no te enteras.
Imposible.
Lo que tú dices no es "mantener los datos eliminados de manera continuada" ya que se sobreescriben automáticamente y por tanto, los pierdes.
Eso no puede pasar con el correo, por ejemplo, o cuando necesitas un archivado permanente.
Se sobreescriben en los ficheros estructurados y se dejan en los de texto. Programación básica.
Un ejemplo: Alpine con mbox. Tengo carpetas desde el año 95 o por ahí, y ningún problema de compactación.
No hablamos de eso.
Claro que hablamos de eso. Alpine usa una buena implementación de mbox, y no te enteras de cuando compacta, porque lo hace.
¿Cuántos años tiene el disco duro donde tienes la 11.1? ¿Te sigue funcionando, se te ha agotado el espacio, se puede iniciar, se han corrompido los archivos? ¿verdad que no? Eso es porque el sistema de archivos "sabe" cómo gestionarlo. El Palomino no se entera, si por él fuera, hubiera seguido aumentando el archivo de la bandeja de entrada hasta reventar el espacio en disco.
Bueno, eso ya lo he dicho desde el principio, han hecho una mala implementación de un buen sistema.
Sistema mediocre + pésima implementación = problemas.
No. Sistema correcto + pésima implementación = problemas.
y permite que le estalle al usuario (es decir, que se le llegue a corromper el archivo). Cuando eso sucede, se le llama "bug", se marca como "crítico" y se corrige >:-)
Claro, no estalla porque lo han hecho bien, No todos, el outlook/exchange estalla cuando llega a cuatro gigas. También él necesita compactar manualmente.
No. El Outlook estalla a los 2 GiB (no a los 4 GiB, como dije antes) "por diseño" no por "falta de compactación". Yo nunca he compactado en Outlook y el archivo *.pst lo dejé con 1,5 GiB de tamaño.
También hace compactación. Antiguamente se podía hacer manualmente, había un procedimiento.
Totalmente opcional, como te he dicho.
El límite de 2 gigas es por usar fat.
No.
*** http://support.microsoft.com/kb/830336
Los archivos de carpetas personales (.pst) de Microsoft Office Outlook 2007 y de Microsoft Office Outlook 2003 tienen un formato diferente y un mayor límite de tamaño de carpeta que en versiones anteriores de Microsoft Outlook. En Outlook 2002 y versiones anteriores, los archivos .pst tenían formato ANSI (American National Standards Institute) y un tamaño total de 2 gigabytes (GB). ***
Nada que ver con tener el sistema de archivos en FAT, que además de que éste admite hasta 4 GiB/archivo.
Claro que tiene que ver. Un programador se daría cuenta enseguida. El límite del FAT es 4 gigabits usando longwords, pero de 2 gigas cuando usas longint, puesto que pierdes un bit en el signo. Es un error básico y típico de programación (típico en C), en el cual no caes porque cuando lo hicieron jamás pensaron que alguien tendrían que guardar gigas de correo, y daba igual, sobraba sitio (total, los discos eran de 8 gigas...). Luego tropezaron con el límite... y ya era tarde, la habían liado parda. Ni siquiera habían previsto que el software no intentara escribir por encima del límite de dos gigas, disparándose en el propio pie. Cuando reescribieron el software, implementaron indices mayores que un longint, lo cual les permitirá esos 20 gigas que dices, y cuatro si usan fat. Y necesitan compactación, automática si lo han hecho bien o manual si no. Está documentado: http://en.wikipedia.org/wiki/.pst Both the .pst and .ost files use a fixed-block-based allocation scheme; the file is enlarged by a fixed amount of bytes, and the file internally maintains information about the allocated and non-allocated blocks. So, when data files like email messages are added to a .pst file, its file size is automatically adjusted by the mail client (if necessary). When mail is deleted from a .pst file, the size of the .pst file will stay the same, marking the space as unallocated so that it will hold future data items. Recently removed data items can actually be recovered from .pst and .ost files. To reduce the size of .pst files, the user needs to compact them.[3] Es un sistema básico de programación, usado por todas partes, con sus variaciones. Simplemente la gente de mozilla lo ha hecho mal, probablemente heredado de la gente de netscape y que no han enmendado.
espero que ese outlook haya corregido el problema del cuelgue irrecuperable a los cuatro gigas >:-)
El límite ahora es de 20 GiB :-)
Porque usais ntfs.
Je, siempre hemos usado ntfs en windows xp y la limitación del outlook 2000 seguía existiendo. Que no, que no es eso :-)
Porque lo habían diseñado para fat con indices de 32 bits menos uno por el signo, o sea, 2³¹.
¿Has probado maildir con 10000 correos en la misma carpeta, sin usar reiserfs? ¿Has probado entonces a hacer una búsqueda textual?
He probado el maildir y me ha funcionado sin problemas. A mí y a millones de personas (desarrolladores, usuarios, programadores y amas de casa...).
Nativa y preferentemente sólo lo usa el kmail como MUA. Otros lo admiten con un parche. En la wikipedia tienes la lista. No son tantos.
Es un sistema más moderno. No todos los proyectos tienen recursos para implementarlo (si Mozilla tiene tantos problemas, imagínate el resto...), como los de Alpine que a punto están -si no lo han hecho ya- de dejar el desarrollo de su cliente de correo >:-)
La Universidad de Washington, que mantenía el Alpine, echó a la calle a un montón de gente, incluyendo los mantenedores de diverso software. Por eso el Alpine no se desarrolla actualmente. Pero es software libre, otros podrían hacerlo.
Windows Mail y Mail, clientes de correo predeterminados de las nuevas versiones de Windows y MacOS, respectivamente, utilizan la misma estrategia de almacenamiento de maildir: un archivo por correo.
Mmmm... razón de más para no usarlos >:-P Me lo imagino con los veintemil correos por lista que tengo yo. Le da una indigestión por atracón que no veas.
Por cierto, que ya te dije cual es el truco para usar maildir como Th... ¿No lo viste? No has comentado sobre ello.
Lo siento pero no. Tener el correo en la nube (imap), aunque tenga la nube a pocos metros, no me convence. Lo necesito en local.
Hablo de local, en el mismo disco. Que no te enteras.
Eso suena a típica excusa de desarrollador para no hacer su trabajo porque requeriría tiempo y esfuerzo extra y sencillamente no está por la labor >:-)
No lo es. Es un razonamiento bien puesto de porqué no le da la gana usar un sistema imperfecto. En su lugar, desarrolló un sistema nuevo de archivo de correo, llamado... mix: http://en.wikipedia.org/wiki/MIX_%28Email%29 - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkuH2nEACgkQU92UU+smfQUiCgCfSAeFaA+2pFI/J/4kv7OcKici o9kAoJP/zmnQOwNcOYIlZ3qPqxjuJz2U =Ho8Z -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Fri, 26 Feb 2010 15:28:01 +0100, Carlos E. R. escribió:
On 2010-02-26 08:35, Camaleón wrote:
Muchos. Me podría apostar el sueldo de un mes, si yo apostara. Lo que pasa es que la mayoría lo han implementado bien y no te enteras.
Imposible.
Lo que tú dices no es "mantener los datos eliminados de manera continuada" ya que se sobreescriben automáticamente y por tanto, los pierdes.
Eso no puede pasar con el correo, por ejemplo, o cuando necesitas un archivado permanente.
Se sobreescriben en los ficheros estructurados y se dejan en los de texto. Programación básica.
Tan básica que no se hace. Los datos sobreescritos se pierden y eso no lo puede un cliente de correo por tanto no existe paralelismo alguno entre ambas acciones (funcionamiento de sistema de archivos y mbox).
Un ejemplo: Alpine con mbox. Tengo carpetas desde el año 95 o por ahí, y ningún problema de compactación.
No hablamos de eso.
Claro que hablamos de eso. Alpine usa una buena implementación de mbox, y no te enteras de cuando compacta, porque lo hace.
No hablamos de eso en esta fase del mensaje. Hablábamos de cómo gestionan los discos la información, y obviamente no funcionan como "recolectores de datos perpetuos" como hace el Palomino. Los datos marcados para borrar son reemplazados por nueva información y eso no lo hace el T. sino que va acumulando datos en lugar de sobreescribirlos o eliminarlos.
El límite de 2 gigas es por usar fat.
No.
*** http://support.microsoft.com/kb/830336
Los archivos de carpetas personales (.pst) de Microsoft Office Outlook 2007 y de Microsoft Office Outlook 2003 tienen un formato diferente y un mayor límite de tamaño de carpeta que en versiones anteriores de Microsoft Outlook. En Outlook 2002 y versiones anteriores, los archivos .pst tenían formato ANSI (American National Standards Institute) y un tamaño total de 2 gigabytes (GB). ***
Nada que ver con tener el sistema de archivos en FAT, que además de que éste admite hasta 4 GiB/archivo.
Claro que tiene que ver. Un programador se daría cuenta enseguida. El límite del FAT es 4 gigabits usando longwords, pero de 2 gigas cuando usas longint, puesto que pierdes un bit en el signo. Es un error básico y típico de programación (típico en C), en el cual no caes porque cuando lo hicieron jamás pensaron que alguien tendrían que guardar gigas de correo, y daba igual, sobraba sitio (total, los discos eran de 8 gigas...). Luego tropezaron con el límite... y ya era tarde, la habían liado parda. Ni siquiera habían previsto que el software no intentara escribir por encima del límite de dos gigas, disparándose en el propio pie.
Cuando reescribieron el software, implementaron indices mayores que un longint, lo cual les permitirá esos 20 gigas que dices, y cuatro si usan fat.
Eso no es lo que has dicho antes. Se nota que has hecho los deberes >:-) Lo que te digo es que no tiene nada que ver con el sistema de archivos FAT o NTFS sobre el que lo uses. Los 2 GiB. de límite viene impuesto por el estándar ANSI, no por el sistema de archivos empleado.
Y necesitan compactación, automática si lo han hecho bien o manual si no. Está documentado:
http://en.wikipedia.org/wiki/.pst
Both the .pst and .ost files use a fixed-block-based allocation scheme; the file is enlarged by a fixed amount of bytes, and the file internally maintains information about the allocated and non-allocated blocks. So, when data files like email messages are added to a .pst file, its file size is automatically adjusted by the mail client (if necessary). When mail is deleted from a .pst file, the size of the .pst file will stay the same, marking the space as unallocated so that it will hold future data items. Recently removed data items can actually be recovered from .pst and .ost files.
To reduce the size of .pst files, the user needs to compact them.[3]
Es un sistema básico de programación, usado por todas partes, con sus variaciones. Simplemente la gente de mozilla lo ha hecho mal, probablemente heredado de la gente de netscape y que no han enmendado.
¿Cuántos archivos .pst has tenido que gestionar y de qué tamaños? Repito: la compactación es "opcional"... o eso o Outlook hace milagros al ocupar tan sólo 1,5 GiB de espacio todos los correos que tengo acumulados desde el año 1999 hasta el 2007 (¡¡7 años!!). Y sin compactar ni una sola vez. Teniendo en cuenta que el T. se ha llevado 650 MiB. en 4 meses, pues ya me dirás.
El límite ahora es de 20 GiB :-)
Porque usais ntfs.
Je, siempre hemos usado ntfs en windows xp y la limitación del outlook 2000 seguía existiendo. Que no, que no es eso :-)
Porque lo habían diseñado para fat con indices de 32 bits menos uno por el signo, o sea, 2³¹.
Que sí, que ya sé que has hecho los deberes y ahora estás intentando corregir el "deja-vu" ;-)
Nativa y preferentemente sólo lo usa el kmail como MUA. Otros lo admiten con un parche. En la wikipedia tienes la lista. No son tantos.
Es un sistema más moderno. No todos los proyectos tienen recursos para implementarlo (si Mozilla tiene tantos problemas, imagínate el resto...), como los de Alpine que a punto están -si no lo han hecho ya- de dejar el desarrollo de su cliente de correo >:-)
La Universidad de Washington, que mantenía el Alpine, echó a la calle a un montón de gente, incluyendo los mantenedores de diverso software. Por eso el Alpine no se desarrolla actualmente. Pero es software libre, otros podrían hacerlo.
Y adaptar el formato maildir requiere de tiempo y recursos, algo que no tienen, por eso lo tuvo que desarrollar un usuario de manera independiente y por eso existe el parche.
Windows Mail y Mail, clientes de correo predeterminados de las nuevas versiones de Windows y MacOS, respectivamente, utilizan la misma estrategia de almacenamiento de maildir: un archivo por correo.
Mmmm... razón de más para no usarlos >:-P
Me lo imagino con los veintemil correos por lista que tengo yo. Le da una indigestión por atracón que no veas.
Lo pruebas y nos cuentas ahora que ya tienes un Windows7 pululando >>:-)
Por cierto, que ya te dije cual es el truco para usar maildir como Th... ¿No lo viste? No has comentado sobre ello.
Lo siento pero no. Tener el correo en la nube (imap), aunque tenga la nube a pocos metros, no me convence. Lo necesito en local.
Hablo de local, en el mismo disco. Que no te enteras.
Aummm... ¿y quieres que instale un servidor de correo sólo porque el T. no es capaz de hacer su trabajo? Lo más lógico sería cambiar de MUA ¿no?
Eso suena a típica excusa de desarrollador para no hacer su trabajo porque requeriría tiempo y esfuerzo extra y sencillamente no está por la labor >:-)
No lo es. Es un razonamiento bien puesto de porqué no le da la gana usar un sistema imperfecto. En su lugar, desarrolló un sistema nuevo de archivo de correo, llamado... mix:
Un sistema de almacenamiento que me parece más lógico que el mbox, por supuesto, aunque sigue dependiendo de un sistema de bloqueo lo que no lo hace recomendable si usas NFS. Y por otra parte no lo usa nadie (ni servidores de correo ni clientes... bueno, salvo el extinto Alpine) porque el maildir, de momento, cumple perfectamente su función. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 02/24/2010 11:30 AM, Camaleón wrote:
El Wed, 24 Feb 2010 10:25:15 +0100, francisco f escribió:
Aviso, entrando en modo "ultra-ranting"...
Mmmm :-)
Editar-Preferencias-Avanzadas - Red y Espacio en disco habilita compactar cuando ahorres tanto espacio en disco.
Pero es peligroso hacerlo online :-(
Culpa del th.
Es bueno que cuando borres no los borres hasta que compactes,
¿Bueno "para quién"? >:-)
Para mí no, desde luego. Para el maldito e ineficiente formato mbox, supongo que sí.
X'-)
por esa caracteristica mucha gente se ha librado de problemas. Si borras y no compactas siempre puedes recuperar el correo que quieras.
Arrrhgg, pero eso no tiene sentido alguno, ¡estamos en el año 2010! y / exijo/ cierta eficiencia y automatismo en un cliente de correo :-)
¿Mutt? >:-p
- Vale que el formato mbox es una porquería, aceptado.
No lo es... es una técnica probada desde hace bastantes años. De hecho, es la misma que emplean las bases de datos en general: se marca un registro como borrado, no se borra de hecho hasta que convenga hacerlo.
- Vale que Thundercito lo use porque, porque... ¿porque le sale de cierto sitio?
Porque es estandard en linux/unix :-)
porque no veo otro motivo para no admitir al menos 2 formatos: maidir y mbox. No digo que den soporte a 20 formatos de almacenamiento distintos, pero sí los más usados.
Pero es que maildir no es estandard, y encima, es más lento en ciertas operaciones e ineficiente en el uso de disco, salvo en reiserfs. Recuerda que hereda del netscape, que se diseñó pensando en FAT.
Lo que "no vale" es que:
1/ A día de hoy sea preciso compactar las carpetas
Igual que las bases de datos.
2/ A día de hoy la operación de compactación sea peligrosa hacerla online (¿tengo que estar pendiente de qué hago o dejo de hacer porque "el señor cliente de correo" está en una operación de compactado?)
Eso es culpa del thundercito. Llevo usando mbox desde el 98 y no me ha dado problemas. Pero uso Pine/Alpine.
3/ No permita seleccionar las carpetas en las que se quiera desactivar esa opción de "cacheo masivo" e indiscriminado.
Eso es culpa del thundercito.
Señores, por mi bandeja de entrada (y por la millones de personas) entran correos espantosamente enormes (no es culpa mía que alguien me envíe correos de 20/30/40 MiB). Y cuando borro un mensaje, espero que se vaya a la papelera (ya lo recuperaré de ahí en caso de que lo necesite). Pues no, hala, a eliminar *y a compactar* toca -dos acciones por una, que hay rebajas-, porque no lo puedo desactivar y los mensajes de cachean, sí o sí.
Como dije, es una técnica bastante antigua y de probada eficacia >:-)
Hala, ya está, ya me he desquitado :-)
Nota: el correo es sólo una pataleta por el casi /1 GiB/ que he liberado tras empezar a compactar compulsivamente el resto de carpetas.
:-) -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Wed, 24 Feb 2010 18:23:28 +0100, Carlos E.R. escribió:
On 02/24/2010 11:30 AM, Camaleón wrote:
Arrrhgg, pero eso no tiene sentido alguno, ¡estamos en el año 2010! y / exijo/ cierta eficiencia y automatismo en un cliente de correo :-)
¿Mutt? >:-p
Aquí lo tengo, ya lo instalo de serie esperando lo peor, es decir, que algún día el Thunderc... al Palomino le pase cualquier cosa. La verdad es que lo instalo porque trabaja en modo consola y necesito un segundo cliente a modo de "fallback".
- Vale que el formato mbox es una porquería, aceptado.
No lo es... es una técnica probada desde hace bastantes años. De hecho, es la misma que emplean las bases de datos en general: se marca un registro como borrado, no se borra de hecho hasta que convenga hacerlo.
"Probada desde hace años" también es la técnica del levantamiento de piedra, es decir, tu coges un pedrusco y lo levantas con la fuerza de tu cuerpo y oye, no falla, ¡la piedra se levanta! Seamos serios. No existe ningún estándar que defina el sistema de almacenamiento de los correos electrónicos y cada uno lo ha ido haciendo a su libre albedrío, con mayor o menor acierto, siguiendo la documentación que proporcionan los RFC y que deben cumplir los mensajes de correo. *** RFC 4155 The application/mbox Media Type http://tools.ietf.org/html/rfc4155 2. About the mbox Database The mbox database format is not documented in an authoritative specification, but instead exists as a well-known output format that is anecdotally documented, or which is only authoritatively documented for a specific platform or tool. (...) A comprehensive description of mbox database files on UNIX-like systems can be found at http://qmail.org./man/man5/mbox.html, which should be treated as mostly authoritative for those variations that are otherwise only documented in anecdotal form. However, readers are advised that many other platforms and tools make use of mbox databases, and that there are many more potential variations that can be encountered in the wild. *** Es decir, que cada implementación del mbox ha seguido su propio camino, y todas se han basado, en mayor o menor medida, en la definición que hizo Qmail... poco más o menos lo que le pasa al "maildir".
- Vale que Thundercito lo use porque, porque... ¿porque le sale de cierto sitio?
Porque es estandard en linux/unix :-)
No, no lo es. No es un "estándar", es lo que ha estado utilizando desde hace años, y años... y la /antigüedad/ no es un factor que sirva para determinar la calidad o la idoneidad de un sistema.
porque no veo otro motivo para no admitir al menos 2 formatos: maidir y mbox. No digo que den soporte a 20 formatos de almacenamiento distintos, pero sí los más usados.
Pero es que maildir no es estandard, y encima, es más lento en ciertas operaciones e ineficiente en el uso de disco, salvo en reiserfs. Recuerda que hereda del netscape, que se diseñó pensando en FAT.
No cuela. No será un estándar "definido" (como tampoco lo es "mbox") pero lo usan la mayoría de los servidores de correo electrónico (Postfix, Courier, Dovecot, Qmail...), por algo será.
Lo que "no vale" es que:
1/ A día de hoy sea preciso compactar las carpetas
Igual que las bases de datos.
Y te aseguro que cualquier bdd que se precie no necesita detenerse para realizar una operación de "compactado offline" >:-)
2/ A día de hoy la operación de compactación sea peligrosa hacerla online (¿tengo que estar pendiente de qué hago o dejo de hacer porque "el señor cliente de correo" está en una operación de compactado?)
Eso es culpa del thundercito. Llevo usando mbox desde el 98 y no me ha dado problemas. Pero uso Pine/Alpine.
3/ No permita seleccionar las carpetas en las que se quiera desactivar esa opción de "cacheo masivo" e indiscriminado.
Eso es culpa del thundercito.
Pues al Palomino le estoy echando la bronca. Y al mbox de refilón, por limitado y no mejorado.
Señores, por mi bandeja de entrada (y por la millones de personas) entran correos espantosamente enormes (no es culpa mía que alguien me envíe correos de 20/30/40 MiB). Y cuando borro un mensaje, espero que se vaya a la papelera (ya lo recuperaré de ahí en caso de que lo necesite). Pues no, hala, a eliminar *y a compactar* toca -dos acciones por una, que hay rebajas-, porque no lo puedo desactivar y los mensajes de cachean, sí o sí.
Como dije, es una técnica bastante antigua y de probada eficacia >:-)
Lo mismo que el levantamiento de piedra: antiguo y de probada eficacia. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Miércoles, 24 de Febrero de 2010 19:07:34 Camaleón escribió:
El Wed, 24 Feb 2010 18:23:28 +0100, Carlos E.R. escribió:
On 02/24/2010 11:30 AM, Camaleón wrote:
Arrrhgg, pero eso no tiene sentido alguno, ¡estamos en el año 2010! y / exijo/ cierta eficiencia y automatismo en un cliente de correo :-)
¿Mutt? >:-p
Aquí lo tengo, ya lo instalo de serie esperando lo peor, es decir, que algún día el Thunderc... al Palomino le pase cualquier cosa.
La verdad es que lo instalo porque trabaja en modo consola y necesito un segundo cliente a modo de "fallback".
- Vale que el formato mbox es una porquería, aceptado.
No lo es... es una técnica probada desde hace bastantes años. De hecho, es la misma que emplean las bases de datos en general: se marca un registro como borrado, no se borra de hecho hasta que convenga hacerlo.
"Probada desde hace años" también es la técnica del levantamiento de piedra, es decir, tu coges un pedrusco y lo levantas con la fuerza de tu cuerpo y oye, no falla, ¡la piedra se levanta!
Seamos serios. No existe ningún estándar que defina el sistema de almacenamiento de los correos electrónicos y cada uno lo ha ido haciendo a su libre albedrío, con mayor o menor acierto, siguiendo la documentación que proporcionan los RFC y que deben cumplir los mensajes de correo.
*** RFC 4155 The application/mbox Media Type http://tools.ietf.org/html/rfc4155
2. About the mbox Database
The mbox database format is not documented in an authoritative specification, but instead exists as a well-known output format that is anecdotally documented, or which is only authoritatively documented for a specific platform or tool.
(...)
A comprehensive description of mbox database files on UNIX-like systems can be found at http://qmail.org./man/man5/mbox.html, which should be treated as mostly authoritative for those variations that are otherwise only documented in anecdotal form. However, readers are advised that many other platforms and tools make use of mbox databases, and that there are many more potential variations that can be encountered in the wild. ***
Es decir, que cada implementación del mbox ha seguido su propio camino, y todas se han basado, en mayor o menor medida, en la definición que hizo Qmail... poco más o menos lo que le pasa al "maildir".
- Vale que Thundercito lo use porque, porque... ¿porque le sale de cierto sitio?
Porque es estandard en linux/unix :-)
No, no lo es. No es un "estándar", es lo que ha estado utilizando desde hace años, y años... y la /antigüedad/ no es un factor que sirva para determinar la calidad o la idoneidad de un sistema.
porque no veo otro motivo para no admitir al menos 2 formatos: maidir y mbox. No digo que den soporte a 20 formatos de almacenamiento distintos, pero sí los más usados.
Pero es que maildir no es estandard, y encima, es más lento en ciertas operaciones e ineficiente en el uso de disco, salvo en reiserfs. Recuerda que hereda del netscape, que se diseñó pensando en FAT.
No cuela.
No será un estándar "definido" (como tampoco lo es "mbox") pero lo usan la mayoría de los servidores de correo electrónico (Postfix, Courier, Dovecot, Qmail...), por algo será.
Lo que "no vale" es que:
1/ A día de hoy sea preciso compactar las carpetas
Igual que las bases de datos.
Y te aseguro que cualquier bdd que se precie no necesita detenerse para realizar una operación de "compactado offline" >:-)
2/ A día de hoy la operación de compactación sea peligrosa hacerla online (¿tengo que estar pendiente de qué hago o dejo de hacer porque "el señor cliente de correo" está en una operación de compactado?)
Eso es culpa del thundercito. Llevo usando mbox desde el 98 y no me ha dado problemas. Pero uso Pine/Alpine.
3/ No permita seleccionar las carpetas en las que se quiera desactivar esa opción de "cacheo masivo" e indiscriminado.
Eso es culpa del thundercito.
Pues al Palomino le estoy echando la bronca. Y al mbox de refilón, por limitado y no mejorado.
Señores, por mi bandeja de entrada (y por la millones de personas) entran correos espantosamente enormes (no es culpa mía que alguien me envíe correos de 20/30/40 MiB). Y cuando borro un mensaje, espero que se vaya a la papelera (ya lo recuperaré de ahí en caso de que lo necesite). Pues no, hala, a eliminar *y a compactar* toca -dos acciones por una, que hay rebajas-, porque no lo puedo desactivar y los mensajes de cachean, sí o sí.
Como dije, es una técnica bastante antigua y de probada eficacia >:-)
Lo mismo que el levantamiento de piedra: antiguo y de probada eficacia.
Saludos,
Vale vale!! que se men saltan los lasgrimones!! Puedes llamarle palo.. digo thundercito!! Salu2 Most people know C is not so high level.... ...Everybody else just got assembler overdose -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 02/24/2010 07:07 PM, Camaleón wrote:
El Wed, 24 Feb 2010 18:23:28 +0100, Carlos E.R. escribió:
On 02/24/2010 11:30 AM, Camaleón wrote:
Arrrhgg, pero eso no tiene sentido alguno, ¡estamos en el año 2010! y / exijo/ cierta eficiencia y automatismo en un cliente de correo :-)
¿Mutt? >:-p
Aquí lo tengo, ya lo instalo de serie esperando lo peor, es decir, que algún día el Thunderc... al Palomino le pase cualquier cosa.
La verdad es que lo instalo porque trabaja en modo consola y necesito un segundo cliente a modo de "fallback".
Pues es posible que el mutt te haga esa compactación de manera segura. A mi me la hace el Alpine - en las mismas carpetas, que esa es una de las cosas que tiene el formato mbox, que es estandard y compatible entre diversos programas.
- Vale que el formato mbox es una porquería, aceptado.
No lo es... es una técnica probada desde hace bastantes años. De hecho, es la misma que emplean las bases de datos en general: se marca un registro como borrado, no se borra de hecho hasta que convenga hacerlo.
"Probada desde hace años" también es la técnica del levantamiento de piedra, es decir, tu coges un pedrusco y lo levantas con la fuerza de tu cuerpo y oye, no falla, ¡la piedra se levanta!
Pues claro. Pero viene el modernismo, y quieres levantarla con una grua comprada en la tienda de al lado. Es una grua muy maja, esbelta, capaz de levantar la piedra y moverla de mil maneras. Pero... ¿que pasa? Ostras, el ingeniero no previó todo y se dobla y parte si la piedra tiene aristas ;-P
Seamos serios. No existe ningún estándar que defina el sistema de almacenamiento de los correos electrónicos y cada uno lo ha ido haciendo a su libre albedrío, con mayor o menor acierto, siguiendo la documentación que proporcionan los RFC y que deben cumplir los mensajes de correo.
*** RFC 4155 The application/mbox Media Type http://tools.ietf.org/html/rfc4155
2. About the mbox Database
The mbox database format is not documented in an authoritative specification, but instead exists as a well-known output format that is anecdotally documented, or which is only authoritatively documented for a specific platform or tool.
(...)
A comprehensive description of mbox database files on UNIX-like systems can be found at http://qmail.org./man/man5/mbox.html, which should be treated as mostly authoritative for those variations that are otherwise only documented in anecdotal form. However, readers are advised that many other platforms and tools make use of mbox databases, and that there are many more potential variations that can be encountered in the wild. ***
Es decir, que cada implementación del mbox ha seguido su propio camino, y todas se han basado, en mayor o menor medida, en la definición que hizo Qmail... poco más o menos lo que le pasa al "maildir".
De hecho, sí hay un standard. El postfix, procmail, sendmail, y todos los programas de correo que he probado en linux lo manejan compatiblemente entre si. Con maildir no ocurre lo mismo.
- Vale que Thundercito lo use porque, porque... ¿porque le sale de cierto sitio?
Porque es estandard en linux/unix :-)
No, no lo es. No es un "estándar", es lo que ha estado utilizando desde hace años, y años... y la /antigüedad/ no es un factor que sirva para determinar la calidad o la idoneidad de un sistema.
¡Claro que si! En software si. Significa que muchos lo conocen y han solventado o "bypasado" sus probblemas. Y si no recuerdo mal, ya etuvimos hablando de esto mismo hace meses/años y te mandé lo que opinaba un experto sobre eso. Experto que estaba diseñando un nuevo tipo de formato de almacenamiento para correo que aunaba las ventajas de ambos sistemas.
porque no veo otro motivo para no admitir al menos 2 formatos: maidir y mbox. No digo que den soporte a 20 formatos de almacenamiento distintos, pero sí los más usados.
Pero es que maildir no es estandard, y encima, es más lento en ciertas operaciones e ineficiente en el uso de disco, salvo en reiserfs. Recuerda que hereda del netscape, que se diseñó pensando en FAT.
No cuela.
No será un estándar "definido" (como tampoco lo es "mbox") pero lo usan la mayoría de los servidores de correo electrónico (Postfix, Courier, Dovecot, Qmail...), por algo será.
Cada uno de manera distinta, independiente. No puedes ponerle el arbol de uno a otro, lo hacen a través de servicios de red.
Lo que "no vale" es que:
1/ A día de hoy sea preciso compactar las carpetas
Igual que las bases de datos.
Y te aseguro que cualquier bdd que se precie no necesita detenerse para realizar una operación de "compactado offline" >:-)
Ni el Alpine tampoco. Pero oye, sí se paran las bases de datos. Si están compactando aguantan en espera las nuevas peticiones.
2/ A día de hoy la operación de compactación sea peligrosa hacerla online (¿tengo que estar pendiente de qué hago o dejo de hacer porque "el señor cliente de correo" está en una operación de compactado?)
Eso es culpa del thundercito. Llevo usando mbox desde el 98 y no me ha dado problemas. Pero uso Pine/Alpine.
3/ No permita seleccionar las carpetas en las que se quiera desactivar esa opción de "cacheo masivo" e indiscriminado.
Eso es culpa del thundercito.
Pues al Palomino le estoy echando la bronca. Y al mbox de refilón, por limitado y no mejorado.
No es culpa del formato, es culpa de cómo lo han programado los de mozilla - los cuales probablemente lo hayan heredado y no tocado mucho. -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Wed, 24 Feb 2010 21:18:10 +0100, Carlos E.R. escribió:
On 02/24/2010 07:07 PM, Camaleón wrote:
(recorto porque si no... me/te conozco y esto acabará mal)
Pues al Palomino le estoy echando la bronca. Y al mbox de refilón, por limitado y no mejorado.
No es culpa del formato, es culpa de cómo lo han programado los de mozilla - los cuales probablemente lo hayan heredado y no tocado mucho.
No te digo que no haya programas que sean capaces de gestionar el formato mbox de forma eficiente. Pero por mucho que me empeñe, no puedo usar Mutt a diario (el KMail ya me estaba dando problemas en la oficina por el nulo soporte del html). Además, es un hecho que el formato maildir se desarrolló -precisamente- para solucionar las carencias/limitaciones del mbox. No veo qué hay de malo en eso, es normal que haya nuevas necesidades que requieran nuevos métodos porque los existentes no cumplen con las exigencias de los servicios actuales. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-02-24 a las 22:44 -0000, Camaleón escribió:
El Wed, 24 Feb 2010 21:18:10 +0100, Carlos E.R. escribió:
On 02/24/2010 07:07 PM, Camaleón wrote:
(recorto porque si no... me/te conozco y esto acabará mal)
:-)
Pues al Palomino le estoy echando la bronca. Y al mbox de refilón, por limitado y no mejorado.
No es culpa del formato, es culpa de cómo lo han programado los de mozilla - los cuales probablemente lo hayan heredado y no tocado mucho.
No te digo que no haya programas que sean capaces de gestionar el formato mbox de forma eficiente. Pero por mucho que me empeñe, no puedo usar Mutt a diario (el KMail ya me estaba dando problemas en la oficina por el nulo soporte del html).
No digo que lo uses para leer correo, pero con que lo uses algo ya te compactará los archivos. Al menos el Alpine me lo hace.
Además, es un hecho que el formato maildir se desarrolló -precisamente- para solucionar las carencias/limitaciones del mbox. No veo qué hay de malo en eso, es normal que haya nuevas necesidades que requieran nuevos métodos porque los existentes no cumplen con las exigencias de los servicios actuales.
El maildir está diseñado para uso por el servidor, no por el cliente. Tiene también pegas gordas, como que carga más el disco (miles de ficheros desperdiciando sitio, busquedas lentas). - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkuFxKYACgkQtTMYHG2NR9VMWACgk95Wgpg5KaEx6J6rQ0YjAquq wSwAnAvn0m7WqfJ7WyM/5KsLx9abJHCL =G0q+ -----END PGP SIGNATURE-----
El Thu, 25 Feb 2010 01:30:23 +0100, Carlos E. R. escribió:
El 2010-02-24 a las 22:44 -0000, Camaleón escribió:
Además, es un hecho que el formato maildir se desarrolló -precisamente- para solucionar las carencias/limitaciones del mbox. No veo qué hay de malo en eso, es normal que haya nuevas necesidades que requieran nuevos métodos porque los existentes no cumplen con las exigencias de los servicios actuales.
El maildir está diseñado para uso por el servidor, no por el cliente.
Los clientes de correo lo han sabido implementar de una forma excelente. De hecho, en KMail 3.5 era el formato predeterminado.
Tiene también pegas gordas, como que carga más el disco (miles de ficheros desperdiciando sitio, busquedas lentas).
Pegas tienen todos. Yo lo estaba usando en KMail 3.5 con los 5 GiB de correos que tengo y funcionaba estupendamente, tanto en un equipo más modesto (Celeron con 1 GiB de ram) como en mi equipo actual (core 4 con 8 GiB de ram). Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
venga venga no te quejes :) por 650 meguillas de nada. A mi como va me parece bien, el que quiera ahorrar espacio que compacte automaticamente, jamas me ha fallado. Claro que si llevas 1 año sin compactar tardara un rato,pero no es para morirse. Llevo usando thundercito desde la 0,5 y oficial en la empresa desde la 0,7 (el purrulu ese si que me daba dolores de cabeza) Si algo pasa como es de texto lo abres con cualquier cosa y lo recuperas. Asi que anquillas a la marrrrr Kerooooooooooooo. saludos -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Thu, 25 Feb 2010 10:17:18 +0100, francisco f escribió:
venga venga no te quejes :) por 650 meguillas de nada.
A mi como va me parece bien, el que quiera ahorrar espacio que compacte automaticamente, jamas me ha fallado. Claro que si llevas 1 año sin compactar tardara un rato,pero no es para morirse. Llevo usando thundercito desde la 0,5 y oficial en la empresa desde la 0,7 (el purrulu ese si que me daba dolores de cabeza) Si algo pasa como es de texto lo abres con cualquier cosa y lo recuperas.
Asi que anquillas a la marrrrr Kerooooooooooooo.
Bueno... parece que al menos son conscientes de la situación: Thunderbird:Pluggable Mail Stores https://wiki.mozilla.org/Thunderbird:Pluggable_Mail_Stores Y el bugzilla está creado desde hace... 10 años >:-) Bug 58308 - support qmail's maildir format https://bugzilla.mozilla.org/show_bug.cgi?id=58308 Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Thursday 25 February 2010 08:39 Camaleón wrote
El Thu, 25 Feb 2010 01:30:23 +0100, Carlos E. R. escribió:
[...]
Tiene también pegas gordas, como que carga más el disco (miles de ficheros desperdiciando sitio, busquedas lentas).
Pegas tienen todos.
Yo lo estaba usando en KMail 3.5 con los 5 GiB de correos que tengo y funcionaba estupendamente, tanto en un equipo más modesto (Celeron con 1 GiB de ram) como en mi equipo actual (core 4 con 8 GiB de ram).
Yo sigo usando maildir con KDE 4.4 :) En cuanto a lo del maildir vs mbox. Lo "malo" de maildir, como dice Carlos, es que son miles de ficheros. Esto se ve en que el disco duro de un PC/portátil no está hecho para trabajar con elevado # de IOPS. La CPU y la RAM no importan realmente cuando la aplicación está "castigando" al disco duro. La ventaja de mbox en portátiles/PCs es que es un único fichero grande por lo que el # de IOPS es bajo. Lo malo es que en un único fichero tienes muchos correos por lo que si ese fichero cae en un sector defectuoso o se pierde ese fichero ... bye bye todos los correos que hay en ese fichero :( Obviamente, para gustos los colores y que cada uno use el que más le guste ;) Yo antes usaba mbox y ahora maildir. Una cosa qu em gusta de KMail (antes y ahora) es que puedes tener un directorio con mbox y otro con maildir. Si arrastras todos los correos de una a otra te lo transforma :) TB lo usé hace muchos años, también llegué a probar Evolution y otros, pero hace tanto que mi opinión no valdría 0:) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.4 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Thu, 25 Feb 2010 21:12:07 +0100, Rafa Grimán escribió:
On Thursday 25 February 2010 08:39 Camaleón wrote
Pegas tienen todos.
Yo lo estaba usando en KMail 3.5 con los 5 GiB de correos que tengo y funcionaba estupendamente, tanto en un equipo más modesto (Celeron con 1 GiB de ram) como en mi equipo actual (core 4 con 8 GiB de ram).
Yo sigo usando maildir con KDE 4.4 :)
¡Suertudo! :-)
En cuanto a lo del maildir vs mbox. Lo "malo" de maildir, como dice Carlos, es que son miles de ficheros. Esto se ve en que el disco duro de un PC/portátil no está hecho para trabajar con elevado # de IOPS. La CPU y la RAM no importan realmente cuando la aplicación está "castigando" al disco duro.
Para eso tengo ReiserFS, un sistema de correo bastante bien ordenado y un buen disco duro al que puedo hacer "sufrir" >:-)
La ventaja de mbox en portátiles/PCs es que es un único fichero grande por lo que el # de IOPS es bajo. Lo malo es que en un único fichero tienes muchos correos por lo que si ese fichero cae en un sector defectuoso o se pierde ese fichero ... bye bye todos los correos que hay en ese fichero :(
Después de tener que soportar el mastodóntico Outlook, que usa un archivo único para dominarlos a todos... huy, no, quiero decir, para correos, contactos y calendario :-P pues no me hizo mucha gracia volver a usar ese sistema. En Outlook es aún peor, porque como se te corrompa el archivo, lo pierdes (casi) todo. Hay que hacer copias diarias de seguridad y es un proceso tedioso.
Obviamente, para gustos los colores y que cada uno use el que más le guste ;) Yo antes usaba mbox y ahora maildir.
Una cosa qu em gusta de KMail (antes y ahora) es que puedes tener un directorio con mbox y otro con maildir. Si arrastras todos los correos de una a otra te lo transforma :)
Si, eso estaba muy bien. De hecho, para migrar correos de KMail a Thunderbird es lo que recomiendan desde Mozilla: crear una carpeta mbox y mover/copiar los mensajes ahí. No hay nada como la flexibilidad de poder elegir.
TB lo usé hace muchos años, también llegué a probar Evolution y otros, pero hace tanto que mi opinión no valdría 0:)
:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-02-26 09:30, Camaleón wrote:
El Thu, 25 Feb 2010 21:12:07 +0100, Rafa Grimán escribió:
En cuanto a lo del maildir vs mbox. Lo "malo" de maildir, como dice Carlos, es que son miles de ficheros. Esto se ve en que el disco duro de un PC/portátil no está hecho para trabajar con elevado # de IOPS. La CPU y la RAM no importan realmente cuando la aplicación está "castigando" al disco duro.
Para eso tengo ReiserFS, un sistema de correo bastante bien ordenado y un buen disco duro al que puedo hacer "sufrir" >:-)
¡Por fin lo has dicho! El Maildir te va bien porque usas Reiserfs, que contraresta sus inconvenientes. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkuHzhIACgkQU92UU+smfQWWEQCfaV1t7rBXP/g3WytA0KmOFjYZ k58AoIipHThHTXf2jdjtUvXD4puYr3wP =LOdv -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Fri, 26 Feb 2010 14:35:14 +0100, Carlos E. R. escribió:
On 2010-02-26 09:30, Camaleón wrote:
El Thu, 25 Feb 2010 21:12:07 +0100, Rafa Grimán escribió:
En cuanto a lo del maildir vs mbox. Lo "malo" de maildir, como dice Carlos, es que son miles de ficheros. Esto se ve en que el disco duro de un PC/portátil no está hecho para trabajar con elevado # de IOPS. La CPU y la RAM no importan realmente cuando la aplicación está "castigando" al disco duro.
Para eso tengo ReiserFS, un sistema de correo bastante bien ordenado y un buen disco duro al que puedo hacer "sufrir" >:-)
¡Por fin lo has dicho! El Maildir te va bien porque usas Reiserfs, que contraresta sus inconvenientes.
Permíteme que lo dude. Que levante la mano quiten tenga un sistema de archivos distinto de reiserfs y use un formato maildir (en kmail o en servidores de correo) Uno, dos, tres, cuatro... ciento cincuenta mil doscientos veinte, ciento cincuenta mil doscientos veintiuno... Vale. Y ahora que levante la mano quien tenga problemas de rendimiento por combinar "semejante" configuración. Hum... ¿nadie? >:-) De hecho, me parece que hoy en día seremos 4 gatos los que seguimos usando reiserfs. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Jueves, 25 de Febrero de 2010 01:30:23 Carlos E. R. escribió:
El 2010-02-24 a las 22:44 -0000, Camaleón escribió:
El Wed, 24 Feb 2010 21:18:10 +0100, Carlos E.R. escribió:
On 02/24/2010 07:07 PM, Camaleón wrote:
(recorto porque si no... me/te conozco y esto acabará mal)
:-) :
Pues al Palomino le estoy echando la bronca. Y al mbox de refilón, por limitado y no mejorado.
No es culpa del formato, es culpa de cómo lo han programado los de mozilla - los cuales probablemente lo hayan heredado y no tocado mucho.
No te digo que no haya programas que sean capaces de gestionar el formato mbox de forma eficiente. Pero por mucho que me empeñe, no puedo usar Mutt a diario (el KMail ya me estaba dando problemas en la oficina por el nulo soporte del html).
No digo que lo uses para leer correo, pero con que lo uses algo ya te compactará los archivos. Al menos el Alpine me lo hace.
Además, es un hecho que el formato maildir se desarrolló -precisamente- para solucionar las carencias/limitaciones del mbox. No veo qué hay de malo en eso, es normal que haya nuevas necesidades que requieran nuevos métodos porque los existentes no cumplen con las exigencias de los servicios actuales.
El maildir está diseñado para uso por el servidor, no por el cliente. Tiene también pegas gordas, como que carga más el disco (miles de ficheros desperdiciando sitio, busquedas lentas).
Yo uso Maildir en Kmail para el correo actual u mbox para las carpetas de historico, donde el correo una vez compactado e indexado se mueve poco. Tambien tengo DBMaIl sobre postgres pero hasta ahora no supone ninguna mejora , quizas para muchos usuarios pero para uno solo.... -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (9)
-
Angel
-
Angel
-
Angel Alvarez
-
Camaleón
-
Carlos E. R.
-
Carlos E.R.
-
francisco f
-
Rafa Grimán
-
Walter