September 19, 2008 at 15:05 · Filed under Python, Sistemas de ficheros
Ya me picaba el gusanillo tras tanto examen y tanta gaita, así que esta vez ha tocado hacer una función que recorra los ficheros del directorio actual y de todos sus subdirectorios. Se basa en una función que mediante las funciones
os.stat()
para saber el tipo de fichero,
os.listdir()
para sacar el contenido de un directorio y una cola para guardar los ficheros que quedan por analizar.
Importamos las funciones necesarias de sus respectivos módulos:
from os import stat,listdir
from os.path import join
from stat import S_ISDIR,S_ISCHR,S_ISBLK,S_ISREG,S_ISFIFO,S_ISLNK,S_ISSOCK
Todas las
stat.S_ISxx()
se pueden sacar también de
os.stat.isXX()
, según la documentación del módulo stat –donde se puede encontrar una función similar a la implementada, pero con recursividad en vez de usar una cola.
Ahora la función (siento que la identación esté hecha con ___, pero es que el editor de WordPress no está hecho para meter código):
def walktree(origen):
____ficheros=[(None,origen),]
cargar la ruta inicial. El primer elemento de la tupla no sería necesario, no habría por qué usar una tupla. La estoy usando para un uso posterior que le quiero dar a esta función de recorrido de directorios.
____while ficheros:
mientras queden ficheros
____ ____ (parent,file)=ficheros.pop()
sacamos el siguiente fichero de la lista (ignorad
parent
)
____ ____print “Fichero: %s”%(file)
____ ____tipo=stat(file).st_mode
obtenemos mediante
os.stat()
el modo del fichero (lo que incluye los permisos, pero también el tipo). Según de qué tipo sea imprimiremos una cosa u otra en pantalla:
____ ____ if S_ISDIR(tipo):
Es un directorio: además de decir que es un directorio…
____ ____ ____ print “Directory”
____ ____ ____ for nuevo_fichero in listdir(file):
…debemos leer sus contenidos con
os.listdir()
e incluirlos en la lista ficheros. Nótese que
listdir()
no devuelve ni el directorio
‘.’
, ni
‘..’
, lo que nos evita ciclos que harían que el algoritmo no acabara nunca hasta agotar la memoria
____ ____ ____ ____ ficheros.insert(0,
____ ____ ____ ____ ____ (None,join(file,nuevo_fichero)))
____ ____ elif S_ISCHR(tipo):
y vamos comprobando otros tipos
____ ____ ____ print “Char. device”
____ ____ elif S_ISBLK(tipo):
____ ____ ____ print “Block device”
____ ____ elif S_ISREG(tipo):
____ ____ ____ print “Regular file”
____ ____ elif S_ISFIFO(tipo):
____ ____ ____ print “Named pipe”
____ ____ elif S_ISLNK(tipo):
____ ____ ____ print “Soft link”
____ ____ elif S_ISSOCK(tipo):
____ ____ ____ print “Socket”
if __name__==’__main__’:
____ walktree(‘.’)
April 9, 2007 at 11:18 · Filed under Linux, Sistemas de ficheros
Si hace unos días comentaba acerca de los atributos de los ficheros en la implementación de OpenBSD del Unix File System (o Fast File System), ahora mismo estaba viendo su equivalente en ext2, el que fuera hasta hace un par de años sistema de ficheros por defecto de Linux, sucedido por ext3 (que es compatible hacia atrás con ext2) y que dentro de poco será sucedido por ext4 (que de momento y por lo general sí es compatible con ext3).
Los dos comandos que permiten trabajar con los atributos de un fichero son lsattr y chattr, respectivamente para mostrarlos o cambiarlos. Ambos forman parte del paquete e2fsprogs.
Los susodichos atributos son 15, a saber:
- ‘A’ evita que se modifique el campo atime (accesed time, última vez que fue accedido un fichero) del fichero cada vez que se accede a él. Puede reducir la carga de I/O del sistema.
- ‘a’ indica que el fichero sólo se puede abrir para añadir si se abre para escritura. Tan sólo root o un proceso con el flag CAP_LINUX_INMUTABLE pueden activar o desactivar esta opción.
- ‘c’ indica que el fichero se guardará comprimido. Por supuesto, la compresión será transparente al acceso al fichero. A la hora de acceder uno no tiene que preocuparse si el fichero está comprimido o no, eso es cosa del kernel. En las versiones actuales del kernel no está implementado, pero se prevee para versiones futuras.
- ‘D’ implica actualizaciones síncronas de los directorios cada vez que son accedidos. Sólo es útil a partir de la rama 2.6.
- ‘d’ excluye al fichero de los programas seleccionados por dump para ser copiados.
- ‘E’ indica que un fichero tiene un error de compresión (los ficheros de la ‘c’). Es usado por los compresores en etapa experimental, y tan sólo puede ser visualizado mediante lsattr, no puede ser cambiado mediante chattr.
- ‘i’ impide que se modifique el fichero o que se cree un enlace hacia él, que se elimine o se renombre. Sólo root o procesos CAP_LINUX_INMUTABLE pueden cambiar este flag.
- ‘j’ hace que todos el fichero sea escrito primero en el journal de ext3 y luego en disco en caso de que el sistema de ficheros esté montado con los modos data=ordered o con data=writeback (con data=journal siempre se hace esto). Sólo root o procesos con la capability CAP_SYS_RESOURCE pueden trastear con esto. Sólo tiene sentido con ext3, no con ext2.
- ‘s’ se asegura de que al borrar un fichero, todos sus bloques son rellenados con ceros en el disco. Esta forma de borrado segura presenta varias limitaciones. En las versiones actuales del kernel no está implementado, pero se prevee para versiones futuras.
- ‘S’ actualiza los ficheros de forma síncrona. Similar a la opción sync de mount.
- ‘T’ manda un directorio a la cima de la jerarquía de directorios. Está relacionado con el asignador de bloques de Orlov presente en la rama 2.6 del kernel desde que se portó la idea de BSD.
- ‘t’ evita el tail-merging. A excepción de una serie de parches ext3 no cuenta con soporte para tail-merging.
- ‘u’ guarda el contenido de un fichero cuando éste es borrado, permitiendo así la recuperación del fichero. En las versiones actuales del kernel no está implementado, pero se prevee para versiones futuras.
- ‘X’, al igual que ‘E’ es usado por los compresores experimentales e indica (y sólo indica, por que no es modificable) que el fichero pese a estar comprimido puede ser accedido directamente.
- ‘Z’ es similar al anterior, salvo porque indica que el fichero comprimido está sucio.
Desde luego, la variedad de opciones que presentan estos atributos es mayor que la del UFS de OpenBSD, y no sólo mayor si no también diferente. Lástima que Linux no cuente con los Secure Levels de OpenBSD porque a nivel de seguridad (más que de usabilidad) le confieren gran potencia.
