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