Mailinglist Archive: opensuse-es (688 mails)
| < Previous | Next > |
Re: [opensuse-es] Re: Thunderbird: archivo "inbox" de 650 MiB
- From: "Carlos E. R." <robin.listas@xxxxxxxxxxxxxx>
- Date: Thu, 25 Feb 2010 22:45:16 +0100 (CET)
- Message-id: <alpine.LSU.2.00.1002252131060.25533@xxxxxxxxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID: <alpine.LSU.2.00.1002252206360.25533@xxxxxxxxxxxxxxxx>
El 2010-02-25 a las 19:38 -0000, Camaleón escribió:
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.
Bueno, eso ya lo he dicho desde el principio, han hecho una mala implementación de un buen sistema.
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.
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.
Porque usais ntfs.
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:
Apparently, it comes with an unsupported third-party maildir driver for the c-client library.
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.
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.
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@xxxxxxxxxxxxxxxx/msg288744.html>
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-----
Hash: SHA1
Content-ID: <alpine.LSU.2.00.1002252206360.25533@xxxxxxxxxxxxxxxx>
El 2010-02-25 a las 19:38 -0000, Camaleón escribió:
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 cornerson 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@xxxxxxxxxxxxxxxx/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-----
| < Previous | Next > |