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

19

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?

usuario1936
fuente
2
El núcleo de esto debería ser simple. La hinchazón opcional que mencionas debe ir encima de un núcleo simple. Alternativamente, espere dos décadas y alguien reinventará la noción de un sistema de archivos.
Trabajo
3
"¿Qué pasa si ya existen en directorios dispares y necesitan permanecer allí?" A veces puedes usar enlaces duros para resolver este problema ...
FrustratedWithFormsDesigner
1
Además, algunas lecturas interesantes sobre el tema: c2.com/cgi/wiki?FileSystemAlternatives
FrustratedWithFormsDesigner
3
No es realmente una solución en Windows 7, pero las nuevas bibliotecas que pueden dar algunas de las funcionalidades que parece interesado en: lifehacker.com/#!5464350/...
DKnight
1
Si quiero poner un archivo en dos carpetas diferentes a la vez, pongo un acceso directo a ese archivo en uno. La desventaja es que si reubica esa carpeta / archivo, el acceso directo no será válido.
Mateen Ulhaq

Respuestas:

17

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.

S.Lott
fuente
44
Muy de acuerdo. En realidad, mucho de lo que OP estaba pidiendo está presente en el proyecto WinFS muerto o moribundo: en.wikipedia.org/wiki/WinFS . Por mucho que el geek dice: "¡Genial!" El experimentado usuario e ingeniero de software en mí dice: "¡Intentando demasiado!"
Adam Crossland
66
"El punto es que el sistema operativo debe hacer lo mínimo y todo es un complemento". Una declaración bastante audaz en una época en la que algunos sistemas operativos contienen un sistema de ventanas incorporado, servicio de indexación de archivos, reproductor multimedia, escritorio remoto, firewall o Netris.
biziclop
1
@biziclop: De acuerdo. Windows ha divergido desde el punto de vista de Linux. Nada sorprendente allí.
S.Lott
1
@ S.Lott No me malinterpreten, estoy de acuerdo con su enfoque, pero de todos modos Windows tiene tanta basura inútil que una característica adicional no hará la diferencia. :)
biziclop
44
Esa es la filosofía de Unix. No es necesariamente correcto. Lo hace (y un compilador C) hace que Unix sea fácil de portar al hardware. También hace que sea lo suficientemente simple para que las personas clonen Unix en los sabores de me gusta -ix que encontramos hoy. Si una característica es útil, y todos los programas la necesitan, como por ejemplo, campos de entrada corregidos ortográficamente, entonces es útil que el entorno de tiempo de ejecución la proporcione. No necesitamos 400 versiones independientes de una barra de cinta.
Tim Williscroft
8

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.

Imbéciles
fuente
99
Tengo que estar en desacuerdo con esto. La mayoría de las personas que no están obligadas a navegar por el sistema de archivos no lo hacen. Abren un procesador de textos y hacen clic en su documento reciente, o buscan en el menú de inicio de Windows 7, etc. Y muchas personas pierden la noción de dónde colocan sus archivos. Sería mucho más fácil para la abuela buscar "recetas de galletas" o "fotos de nietos" o cualquier otra cosa que mantener una jerarquía de carpetas.
Matthew leyó el
16
Esto puede sorprenderle: la gente común no entiende el sistema de archivos. No tienen la menor idea. Y no me refiero a un FS de estilo Unix con sus puntos de montaje, enlaces simbólicos y enlaces duros, sino una estructura de directorio estándar con archivos.
biziclop
2
@Morons, mi abuela nunca sabe dónde pone las cosas. Gmail ya ha cambiado mi paradigma deseado a un sistema de etiquetado, especialmente con filtros para etiquetar automáticamente las cosas. Creo que el paradigma del sistema de archivos se implementó en gran medida debido a la simplicidad de la programación de estructuras de árbol. También facilita el direccionamiento desde una perspectiva de programación. ¿Cómo especificaría la ubicación de un documento en un sistema basado en etiquetas? No digo que no se pueda hacer, pero los detalles deben ser resueltos.
zzzzBov
3
¿Compra sus archivadores llenos de miles de carpetas y documentos necesarios para el funcionamiento del propio gabinete, que debe navegar a través y alrededor pero tenga cuidado de no tocar? ¿Parece que su archivador se abre en una ubicación diferente cada vez que saca el cajón? Etc. etc. Estoy de acuerdo con Matthew y biziclop - "Todos los días" la gente no lo entiende.
Nicole
2
Tengo un título de CS. Pero no sé en qué carpetas coloca Windows en qué archivos. Especialmente Desktop, StartMenu, QuickLaunch y todas las demás carpetas predeterminadas específicas del usuario / sistema. (Ese sistema de ayuda M $ no me ayuda a explicarme cómo presionar un botón). Necesito instalar CygWin para poder buscar mis propios archivos, porque las nuevas funciones de búsqueda de M $ ya no encuentran archivos existentes simples como en win2k. Deshabilitar las características incorrectas como hide-system-files, hide-file-extensiones ya no resuelve la mayoría de los problemas. Renuncié a Windows, cuando me vi obligado a trabajar en el (nuevo) winXP.
comonad
6

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.

biziclop
fuente
¿Rememebr CP / M en un disco duro de 5 MB? Cientos y cientos de archivos pasando. ¡HORRIBLE!
rapid_now
@quickly_now Ah, el buen viejo CP / M. :)
biziclop
3

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.

Paul Nathan
fuente
Las versiones modernas de NTFS / Windows hacen oferta de versiones. No es exactamente en tu cara, pero existe. Sin embargo, no puedo decir cómo se compara con VMS.
Shog9
2

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.

John Bode
fuente
1

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
Jerry Coffin
fuente
1
DIR podría ser capaz de mostrarlo, pero la copia de seguridad de un archivo con secuencias alternativas es terriblemente difícil , especialmente para algún otro sistema. Por ejemplo, la mayoría de las unidades NAS de hoy en día usan Linux, y los sistemas de archivos allí no manejan transmisiones alternativas en absoluto. Copie el archivo ... y todo el material alternativo simplemente desaparece.
rapid_now
Sí, he notado que la mayoría de los sistemas NAS son ... desafiados (y esta tampoco es la única forma). Sin embargo, para las cosas reales de copia de seguridad y restauración, no causa ningún problema (al menos si el software en cuestión está escrito de manera competente): BackupReadserializará todas las secuencias y BackupWritereconstituirá el archivo (con secuencias alternativas) desde formato serializado
Jerry Coffin
Depende de si desea que los archivos respaldados sean legibles directamente en el NAS. Si lo hace (y evita la necesidad de programas de restauración especiales), entonces está atascado con archivos simples.
rapid_now