¿Cómo nos cargamos con el sistema de archivos (jerárquico) como estructura de datos básica?

Soy autodidacta y no tengo un título de CS. Cuanto más he estado aprendiendo sobre la estructura de datos, más me pregunto, hoy en día, ¿cómo estamos todavía cargados con el sistema de archivos, con directorios y archivos, como la estructura básica de almacenamiento de datos en el sistema operativo?

Entiendo la simplicidad, pero parece que hoy en día podría haber más opciones disponibles de forma nativa. Hasta donde yo sé, el único proyecto para mejorar la funcionalidad básica del sistema de archivos fue ReiserFS, donde se podía saber qué línea de un archivo fue cambiado por quién y cuándo.

Por ejemplo, si pudiera tener un etiquetado nativo para los archivos, donde pudiera etiquetar imágenes, diagramas, documentos de procesamiento de texto, un repositorio de código completo, todo como perteneciente a un solo proyecto, eso sería realmente útil para mí. Como estoy atascado en el paradigma del sistema de archivos, sé que podría ponerlos en una sola carpeta / directorio, pero ¿qué pasa si ya existen en directorios diferentes y necesitan permanecer allí? Sé que existen programas que pueden hacer esto, pero ¿por qué no están en el sistema de archivos?

Algo que sería bueno tener es algún tipo de característica relacional en el sistema de archivos, como se obtiene con RDBMS. Entiendo que se suponía que eso era parte de Vista / 7, pero que también cayó de la lista de características.

Claro, cualquier programa puede almacenar un archivo binario y tener cualquier estructura de datos que desee, ¿por qué el sistema operativo no podría ofrecer formas más complejas de almacenar datos, más allá de la simple jerarquía del sistema de archivos?

Comience con esto: http://en.wikipedia.org/wiki/Unix_File_System

Lea esto: http://www.unix.org/what_is_unix/history_timeline.html

Luego lea esto: http://www.amazon.com/UNIX-Filesystems-Evolution-Design-Implementation/dp/0471164836

Hay una respuesta simple a "¿por qué el sistema operativo no podría ofrecer formas más complejas de almacenar datos, más allá de la simple jerarquía del sistema de archivos?"

Porque es demasiado para el sistema operativo.

Para eso están las bibliotecas y los paquetes de aplicaciones.

Oracle, por ejemplo, le venderá un conjunto de características similares a un sistema de archivos que usted administra con el conjunto de herramientas de Oracle.

Python usa la biblioteca DBM para crear estructuras de almacenamiento en disco muy sofisticadas.

CouchDB y Mongo (y otros) son estructuras de almacenamiento muy sofisticadas que ofrecen algunas características similares a las de una base de datos.

El punto es que el sistema operativo debe hacer lo mínimo y todo es un complemento.

La respuesta corta es: Todos los días la gente entiende el sistema de archivos. Les recuerda a un archivador. Piense en las páginas web e incluso en las aplicaciones Fat, ¿por qué cree que Tabsson tan populares? Las personas pueden identificarse con ellos y comprenderlos rápidamente.

Imágenes que intentan enseñarle a la abuela a buscar un DB en un archivo basado en etiquetas de propiedad. Con el sistema de archivos, la abuela sabe que el archivo es simplemente donde lo puso .

Incluso con WinFS, no creo que MS vaya a deshacerse del aspecto del sistema de archivos.

Hay una pequeña verdad en cada respuesta aquí, pero no creo que sea toda la verdad.

Lo que usted enumera son en su mayoría características que los usuarios y desarrolladores pasan por alto todos los días.

Las personas no entienden el sistema de archivos basado en árboles más de lo que entenderían uno basado en DAG.

Y no hay absolutamente ninguna excusa para los patéticos apéndices de los nombres de archivos llamados extensiones. No solo son completamente inadecuados para su propósito (identificando el tipo de archivo) sino también una fuente interminable de molestias para los usuarios.

La razón por la que todavía los estamos usando es una mezcla de una actitud de "eso servirá" y la necesidad real de mantener la compatibilidad con el código anterior. Un nuevo enfoque para almacenar archivos significaría un cambio radical en la API básica de E / S de archivos, haciendo que la mayoría del código existente sea inútil. O eso o tienes que caminar de puntillas alrededor de ellos, manteniendo la API heredada. Recuerde PROGRA ~ 1.

Creo que por las razones anteriores, aunque el futuro podría contener sistemas de archivos más especializados para aplicaciones especiales, pero aunque las arquitecturas de PC de escritorio y portátiles actuales sobreviven, estamos atrapados en el sistema de archivos en gran parte basado en árboles con su falta de metadatos y Sus pequeñas extensiones horribles.

Ahora voy a cambiar de lado.

Debido a que está a nuestro alrededor, nunca apreciamos cuán increíblemente poderosa es la metáfora del árbol. En mi disco duro tengo varios cientos de miles de archivos. Si tengo que encontrar uno, rara vez lleva más de un minuto, incluso si sé muy poco sobre el archivo. Ahora imagine la misma tarea sin ninguna estructura, solo una lista plana de nombres, desplazándose sin cesar.

Sin embargo, todas las operaciones son sencillas, no hay acción espeluznante a distancia, nada que me haga perder el control.

En realidad, implementé una tienda de documentos con metadatos enriquecidos y una jerarquía basada en DAG una vez. (Ni siquiera era un DAG de forma libre, era estrictamente una metaestructura de dos niveles y los documentos, que podrían ser hijos de una colección de nivel 1 o de nivel 2. Así que es realmente simple).

Obviamente, el requisito de que los nombres de los documentos deberían ser únicos dentro de una colección tenía que permanecer.

Y luego los problemas comenzaron a fluir. ¿Qué sucede si abre una colección y cambia el nombre del documento a algo que entre en una colección diferente a la que también pertenece el documento? Mostramos un mensaje de error pero los usuarios estaban completamente desconcertados. (Estos son los mismos usuarios que solicitaron este requisito).

Intentaron eliminar un documento, pero todo lo que hicieron fue eliminarlo de la colección. Por lo tanto, todavía apareció en los resultados de búsqueda. Lo intentamos al revés también, pero luego se quejaban de que habían eliminado un documento de la colección A y mágicamente desapareció de la colección B. Por lo tanto, necesitábamos una operación de "desvinculación" y una eliminación completa.

Eventualmente admitimos la derrota, afortunadamente aún a tiempo.

Sin embargo, las facetas de búsqueda adicionales que los metadatos hicieron posible funcionaron absolutamente.

Para ser honesto, apenas toco metadatos en mis archivos en la Mac. Creo que en los últimos 5 años de uso de OSX (que admite comentarios, etc.), he usado metadatos en quizás 2 archivos. No digo que sea una mala idea.

No estoy seguro de cómo la sobrecarga del etiquetado es pragmática para mí.

Creo que la mejor característica del sistema de archivos que conozco sería un sistema de versiones de nivel de sistema de archivos ... que funcione con particiones cruzadas. Se realizó en VAXen en los años 70 y principios de los 80, sin saber por qué no se dio cuenta de Unix y NTFS / Windows.

He trabajado con sistemas de archivos no jerárquicos en minis antiguos como HP3000 y Encore / Gould. No tenías directorios; tenías un grupo y una cuenta, y los archivos fueron nombrados como " grupo . cuenta . archivo ", como "users.jbode.myfile1", "dev.jbode.main", etc.

Ahora, estos son sistemas antiguos , donde las cuotas individuales de espacio en disco estaban en los megabytes individuales, por lo que no es que necesitara demasiados niveles para organizar sus cosas, pero desde la perspectiva del usuario y del programador, los sistemas jerárquicos son mucho mejores.

No veo dónde (al menos algunos) sistemas de archivos actuales realmente necesitan hacer mucho [Editar: cualquier cosa, para ser sincero] para admitir etiquetas. Cuando llegue al final, las etiquetas de soporte significan poco más que algunos datos adicionales asociados con un archivo, pero no están escritos en la secuencia de bytes para ese archivo.

NTFS (para elegir un ejemplo que se usa ampliamente ) puede hacerlo bien: en lo que respecta a NTFS, un archivo no es necesariamente una sola secuencia de bytes. En NTFS puede asociar un número arbitrario de flujos de datos con un solo nombre de archivo. Cada archivo tiene un "flujo primario" (posiblemente vacío) que no tiene un nombre. Sin embargo, también puede tener un número arbitrario de otras secuencias, cada una de las cuales debe tener un nombre. Con esto, sería realmente trivial agregar una secuencia llamada (solo por ejemplo) "etiquetas" a un archivo existente, y (obviamente) escribir sus etiquetas en esa secuencia.

Después de eso viene la parte algo más difícil: hacer que sus herramientas hagan uso de las etiquetas que coloca allí. Idealmente, es probable que desee indexarlos para una búsqueda rápida, de modo que pueda hacer cosas como crear un "directorio virtual" de todos los archivos con una etiqueta específica.

Al menos desde mi perspectiva, el sistema de archivos ya tiene lo que se necesita: se supone que almacena y recupera los datos, y puede hacerlo perfectamente bien en este momento. Hacer uso de esos datos es el trabajo de otras herramientas. Esas herramientas no existen actualmente, pero la infraestructura del sistema de archivos para soportarlas sí.

Si se me permite ser cínico por un momento, diría que es inevitable que esta característica de NTFS permanezca casi completamente ignorada y desconocida. Después de todo, es simple de usar y no requiere ninguna API especial ni nada más. Puede usarlo bastante bien en C, C ++ completamente portátil o cualquier otra cosa que le permita especificar un nombre de archivo arbitrario. Aquí hay un breve código para demostrar la creación de un archivo con un AFS:

#include <fstream>

int main() {
    std::ofstream out("test.txt");
    std::ofstream tag("test.txt:tags");

    out << "This is the output file";
    tag << "tag1 tag2";

    return 0;
}

Y, aquí hay un código para leer y mostrar las etiquetas:

#include <fstream>
#include <iterator>
#include <iostream>
#include <string>

int main() { 
    std::ifstream tags("test.txt:tags");

    std::copy(std::istream_iterator<std::string>(tags),
          std::istream_iterator<std::string>(),
          std::ostream_iterator<std::string>(std::cout, " "));
    return 0;
}

Todo muy simple y fácil. Tenga en cuenta que aunque solo he escrito un dato trivial allí, puede tratar un AFS como cualquier otro archivo: todas las "cosas" habituales funcionan igual que con cualquier otra cosa. En una visualización de directorio normal, todo lo que se mostrará es la secuencia principal (por ejemplo, el tamaño que se muestra para el archivo será el tamaño de la secuencia primaria), pero si desea verlo, también dir puede mostrar información sobre secuencias alternativas con la /Rbandera Por ejemplo, una lista para el archivo creado anteriormente se ve así:

03/16/2011  08:22 PM                23 test.txt
                                     9 test.txt:tags:$DATA
               1 File(s)             23 bytes