The FAT file system (FAT FS) enables the inserting developer from Zeeis to easily and integrates MS-DOS or the window compatible FAT file system using the nature mutually and all main operating system all equipment rapidly. It tested the use in several true time operating system and the canned food not to have RTOS. This high performance source code was the minimum memory consumption in RAM and ROM optimal, was cheap and is high speed.
In 2008, the Zeeis FAT file system product shipped the completely successful 25,000,000 equipment, is the leading filing system product for mobile, the electrical appliances and the storage application.

Bueno, todos aquellos que tengan un reproductor de audio portatil (MP3 player) de los comunes, habrán notado que siempre que les copian archivos de música estos son luego reproducidos por el aparato en el orden en que fueron grabados por lo que, muchas veces, un disco queda desordenado :S

Para solucionar este problema, hay 3 soluciones:

• Una es que graben uno a uno los temas → Aunque es mucho trabajo y la descarto.
• Otra, es usar algun script de los que ordenan una vez grabados → Pero no pude encontrar el que tenía
• Así que, de esa forma se arriba a ésta, es decir la tercer solución la cual es un comando para la consola. El cual ordenará alfabeticamente todos los archivos de la carpeta y luego los copiara a nuestro reproductor en dicho orden.

El comando es:

find . -type f -print0 | sort -z -n  | xargs -0 cp --target-directory='/tmp'

En donde /tmp es la ruta a la carpeta destino, es decir la carpeta de su MP3. Vale aclarar que el comando es recursivo, por lo que el mismo, copiara tanto todos los archivos de la carpeta como todos aquellos dentro de las sub-carpetas del directorio donde estemos.

La forma más fácil de usarlo, es ir a la carpeta que queremos copias con thunar/nautilus/dolphin/etc, darle al click derecho/abrir terminal aquí y simplemente usar el comando.

Visto en Ubuntu Forums

A (small) part of the Linux VFS module of the Designer Graphix Linux Internals training programme.

Referenced kernel ver: 2.6.30

Once extracted, see the

 fs/fat

folder.

_Tip:_
For ease of code browsing, do ‘make tags’ (or ‘ctags -R’) in the root folder of the kernel soure tree.

cd fs/fat

Note: Here the focus is on part of the MSDOS – Linux VFS kernel implementation, mainly the disk-related part, i.e., the superblock and inode objects. We don’t attempt to cover the Dcache/dentry, page cache (address operations) and just touch upon the process<–>filesystem relationship stuff (at least for now).

_Tip:_
To gain some insight into the physical structure / arch of the MSDOS (and [v]fat) filesystem, see this page.
The <linux/msdos_fs.h> header mirrors much of this.

For example, the FAT16 boot record (boot sector) structure is nicely seen here; it’s Linux layout is here:
include/linux/msdos_fs.h:struct fat_boot_sector
(can browse it via the superb LXR tool here).

Superblock Setup

In namei_msdos.c:

...
static struct file_system_type msdos_fs_type = {
	.owner          = THIS_MODULE,
	.name           = "msdos",
	.get_sb         = msdos_get_sb,
	.kill_sb        = kill_block_super,
	.fs_flags       = FS_REQUIRES_DEV,
};

static int __init init_msdos_fs(void)
{
	return register_filesystem(&msdos_fs_type);
}
...

So, the routine invoked upon mounting is msdos_get_sb :

Following the call chain in msdos_get_sb (see the flow diagram), control hits VFS fill_super routine, which implicitly invokes the msdos_fill_super routine (function pointer passed via a parameter). This is the MSDOS-filesystem-specific routine to initialize the superblock.

This invokes the fat_fill_super routine which actually allocates memory for and initializes the MSDOS superblock structure – struct msdos_sb_info ; this is the data structure that MSDOS FS uses to map it’s filesystem superblock into the kernel’s VFS struct super_block structure. This routine reads from disk the MSDOS superblock, parses mount options, makes validity checks on the filesystem superblock, and finally intializes the structure.

...
        sb->s_magic = MSDOS_SUPER_MAGIC;
        sb->s_op = &fat_sops;
        sb->s_export_op = &fat_export_ops;
        sbi->dir_ops = fs_dir_inode_ops;
					<< sbi is the  msdos_sb_info structure >>
...
        bh = sb_bread(sb, 0);           << Block read off disk, sector 0 - boot sector >>
        if (bh == NULL) {
                printk(KERN_ERR "FAT: unable to read boot sector\n");
                goto out_fail;
        }

        b = (struct fat_boot_sector *) bh->b_data;
...

        sbi->cluster_size = sb->s_blocksize * sbi->sec_per_clus;       << Init msdos superblock >>
        sbi->cluster_bits = ffs(sbi->cluster_size) - 1;
        sbi->fats = b->fats;
        sbi->fat_bits = 0;              /* Don't know yet */
        sbi->fat_start = le16_to_cpu(b->reserved);
        sbi->fat_length = le16_to_cpu(b->fat_length);
        sbi->root_cluster = 0;
        sbi->free_clusters = -1;        /* Don't know yet */
        sbi->free_clus_valid = 0;
        sbi->prev_free = FAT_START_ENT;

        if (!sbi->fat_length && b->fat32_length) {
                struct fat_boot_fsinfo *fsinfo;
                struct buffer_head *fsinfo_bh;

                /* Must be FAT32 */
                sbi->fat_bits = 32;
                sbi->fat_length = le32_to_cpu(b->fat32_length);
                sbi->root_cluster = le32_to_cpu(b->root_cluster);
...

It then sets up the root inode as well (including getting the superblock’s s_root field to point to the root inode.

...
        root_inode = new_inode(sb);
        if (!root_inode)
                goto out_fail;
        root_inode->i_ino = MSDOS_ROOT_INO;
        root_inode->i_version = 1;
        error = fat_read_root(root_inode);
        if (error < 0)
                goto out_fail;
        error = -ENOMEM;
        insert_inode_hash(root_inode);
        sb->s_root = d_alloc_root(root_inode);
...

Inodes Setup

The inode represents any kind of file object. However, the VFS distinguishes between inode operations to be enacted on a directory object versus those to be enacted on a regular file (I/O) object.

So we have two ‘inode_operations’ structures that the filesystem implements – one for directory operations – creation, deletion, lookup, rename, etc – anything that operates directly on a “directory” (think “.” file) object, and one ‘inode_operations’ structure for actual file IO.

Inode Create and Init

Whenever a new file is created, the filesystem has to allocate an inode. The ‘alloc_inode’ method of the superblock’s super_operations does this.
For MSDOS, we have (infs/fat/inode.c):

static const struct super_operations fat_sops = {
 .alloc_inode    = fat_alloc_inode,
 .destroy_inode  = fat_destroy_inode,
 .write_inode    = fat_write_inode,
 .delete_inode   = fat_delete_inode,
 .put_super      = fat_put_super,
 .write_super    = fat_write_super,
 .statfs         = fat_statfs,
 .clear_inode    = fat_clear_inode,
 .remount_fs     = fat_remount,
.show_options   = fat_show_options,
};

...

The fs/inode.c:new_inode() routine is invoked to obtain a new inode.
It in turn, invokes the alloc_inode() routine.

static struct inode *alloc_inode(struct super_block *sb)
{
 struct inode *inode;

 if (sb->s_op->alloc_inode)
    inode = sb->s_op->alloc_inode(sb);
 else
    inode = kmem_cache_alloc(inode_cachep, GFP_KERNEL);

 if (inode)
 return inode_init_always(sb, inode);
 return NULL;
}

So, we can see that alloc_inode invokes the filesystem-specific method from the filesystem’s superblock operations.
This is the ‘fat_alloc_inode‘ method (see the fat_sops structure above):

In fs/fat/inode.c :

...
static struct kmem_cache *fat_inode_cachep;

static struct inode *fat_alloc_inode(struct super_block *sb)
{
 struct msdos_inode_info *ei;
 ei = kmem_cache_alloc(fat_inode_cachep, GFP_NOFS);
 if (!ei)
    return NULL;
 return &ei->vfs_inode;
}
...

Notice how a custom slab cache (to hold MSDOS inode objects) is used to rapidly perform the allocation (& subsequent free back into the cache).

The MSDOS/FAT Directory Inode Operations

Initialize an inode:
The ‘create’ method of the file_operations structure, therefore, is setup to point to a method to do this for the particular filesystem implementation.

So, we see in fs/fat/namei_msdos.c :

static const struct inode_operations msdos_dir_inode_operations = {
        .create         = msdos_create,
        .lookup         = msdos_lookup,
        .unlink         = msdos_unlink,
        .mkdir          = msdos_mkdir,
        .rmdir          = msdos_rmdir,
        .rename         = msdos_rename,
        .setattr        = fat_setattr,
        .getattr        = fat_getattr,
};

static int msdos_fill_super(struct super_block *sb, void *data, int silent)
{
        int res; 
        res = fat_fill_super(sb, data, silent, &msdos_dir_inode_operations, 0);
...

fs/fat/inode.c:

…

/*
 * Read the super block of an MS-DOS FS.
 */
int fat_fill_super(struct super_block *sb, void *data, int silent,
                   const struct inode_operations *fs_dir_inode_ops, int isvfat)
{
...
	sbi->dir_ops = fs_dir_inode_ops;
...

If a userspace process attempts to create a new file on an MSDOS filesystem, the kernel VFS ultimately switches the request to the fs_dir_inode_ops function, in this case, the create method which is msdos_create.

The MSDOS/FAT File Inode Operations

In fs/fat/inode.c :

The fat_fill_inode routine [1] is the one responsible for initializing the inode, for both a directory object as well as a non-directory object.

...
/* doesn't deal with root inode */
static int fat_fill_inode(struct inode *inode, struct msdos_dir_entry *de)
{
        struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
...
        if ((de->attr & ATTR_DIR) && !IS_FREE(de->name)) {
                inode->i_generation &= ~1;
                inode->i_mode = fat_make_mode(sbi, de->attr, S_IRWXUGO);
                inode->i_op = sbi->dir_ops;
    				<< sbi->dir_ops is the same structure we saw above, viz,
                              the msdos_dir_inode_operations structure. >>
                inode->i_fop = &fat_dir_operations;

...
       } else { /* not a directory */
                inode->i_generation |= 1;
                inode->i_mode = fat_make_mode(sbi, de->attr,
                        ((sbi->options.showexec && !is_exec(de->name + 8))
                         ? S_IRUGO|S_IWUGO : S_IRWXUGO));
                MSDOS_I(inode)->i_start = le16_to_cpu(de->start);
                if (sbi->fat_bits == 32)
                    MSDOS_I(inode)->i_start |= (le16_to_cpu(de->starthi) << 16);

                MSDOS_I(inode)->i_logstart = MSDOS_I(inode)->i_start;
                inode->i_size = le32_to_cpu(de->size);
                inode->i_op = &fat_file_inode_operations;
                inode->i_fop = &fat_file_operations;
                inode->i_mapping->a_ops = &fat_aops;
...

It first switches on whether the ‘file object’ to be created is a directory or not.
Furthermore, as we can see above, the inode has two operation pointers:

i_op: for the inode methods operating on the inode object itself, and

i_fop: for the methods that operate on the open file object that the inode represents.

In fs/fat/file.c :

...
const struct inode_operations fat_file_inode_operations = {
        .truncate       = fat_truncate,
        .setattr        = fat_setattr,
        .getattr        = fat_getattr,
};

In fs/fat/file.c :

...
const struct file_operations fat_file_operations = {
        .llseek         = generic_file_llseek,
        .read           = do_sync_read,
        .write          = do_sync_write,
        .aio_read       = generic_file_aio_read,
        .aio_write      = generic_file_aio_write,
        .mmap           = generic_file_mmap,
        .release        = fat_file_release,
        .ioctl          = fat_generic_ioctl,
        .fsync          = file_fsync,
        .splice_read    = generic_file_splice_read,
};              

...

These will be invoked via the usual VFS route (filp->f_op->foo), where foo is the method – system call – invoked from the userspace process (or thread).

In fact, we can see from the above implementation, that the MSDOS filesystem (and indeed all the FAT variants – MSDOS (FAT12), FAT16, FAT32 (VFAT)), invoke the generic VFS methods for read, write, lseek, mmap and aio_[read|write].
Which, of course, is in a large sense, the whole point: once the underlying filesystem “driver” (such as MSDOS or FAT) maps it’s physical structure to the kernel VFS expectations – to it’s (VFS’s) data structures, the kernel goes ahead and treats it as a (virtual) filesystem; I/O proceeds using the mechanisms built-in.

VFS component

Corr. MSDOS/FAT component

Macro to access it

struct super_block

struct msdos_sb_info

MSDOS_SB

struct inode

struct msdos_inode_info

MSDOS_I

[1] When does the fat_fill_inode routine get invoked?

The fat_build_inode function invokes it. So what invokes fat_build_inode ?

cscope can provide us with an answer (output below, on the 2.6.30 kernel):

Functions calling this function: fat_build_inode

  File          Function       Line
0 inode.c       fat_get_parent 752 inode = fat_build_inode(sb, de, i_pos);
1 namei_msdos.c msdos_lookup   220 inode = fat_build_inode(sb, sinfo.de, sinfo.i_pos);
2 namei_msdos.c msdos_create   306 inode = fat_build_inode(sb, sinfo.de, sinfo.i_pos);
3 namei_msdos.c msdos_mkdir    394 inode = fat_build_inode(sb, sinfo.de, sinfo.i_pos);
4 namei_vfat.c  vfat_lookup    732 inode = fat_build_inode(sb, sinfo.de, sinfo.i_pos);
5 namei_vfat.c  vfat_create    788 inode = fat_build_inode(sb, sinfo.de, sinfo.i_pos);
6 namei_vfat.c  vfat_mkdir     882 inode = fat_build_inode(sb, sinfo.de, sinfo.i_pos);

(c) 2009 Kaiwan N Billimoria, Designer Graphix.

Rule through the fear of force rather than through force itself. If we use our strength wisely, we shall cow thousands of worlds with the example of a select few. -Grand Moff Tarkin from“The Tarkin Doctrine”

Apparently a new Linux patch will either create a legacy 8.3 file name when the file name is eight characters or less plus extension -or- a LFN (Long File Name) if the file name exceeds the 8.3 convention, but *never* both.

Apparently the Microsoft patent that TomTom GPS devices apparently infringed on covered the creation of both types of file names for a file with a Long File Name, this new approach should ensure that any version of Windows later than Windows 95 OEM Service Release 2 will still understand long file names on FAT32 volumes as written when mounted by Linux, and fills the “8.3″ filename value with random meaningless data that does not constitute a “file name” in order to avoid hitting the Microsoft patent for having both names at once.

Apparently the patch -also- has to be careful with the junk data in the legacy 8.3 field though or else it could trip a Windows XP bug that could cause a system crash.

The legal theory behind this is that since the garbled data in that field does not constitute a file name, it does not trip over Microsoft’s patent.

Clearly the FAT32 file system is garbage, since its cluster size no longer makes efficient use of the size of storage it is typically used on (SD cards and miniature hard drives with dozens or hundreds of gigabytes), is prone to data corruption issues, and cannot store any individual file that is larger than four gigabytes. This takes a side seat of course to the fact that various bits of its behaviors are controlled by a giant patent troll (Microsoft), but even on sheer technical merit FAT32 is getting awfully long in the tooth.

It’s clear that the Linux Foundation suggestion of device makers coming up with a platform-neutral standard that nobody can sue over is probably the best thing to do going forward.

The fact remains that there are millions on millions of devices which still depend on FAT32, so it’s vital that these patent problems can be worked around.

Microsoft has said that they do not intend to go after individual Linux users, which sounds nice on the surface but would be impractical in practice.

In practice, they are going after device makers that implement FAT32.

In the end this can only have the unintended effect of lighting a fire under the collective ass of GPS and MP3 player makers since they are the ones being extorted, to move on to better technology that does not require anything controlled exclusively by our friends at MICROS~1.

"The more you tighten your grip, Tarkin, the more star systems will slip through your fingers."

Todos sabemos que son los archivos o por lo menos tenemos pequeñas o grandes ideas que los definieran,  pero un sistema de archivos es un poco más complejo por eso explicaré un  poco su terminología y el uso que a éstos se les da en el mundo de los Sistemas Operativos…

Un Sistema de archivos no es más que la estructura básica y vital de toda la información que guardamos, editamos, borramos, copiamos etc…en nuestro ordenador siendo toda esta información accesada a través de gestores de archivos  en sus respectivos OS.

Podríamos decir entonces que los sistemas de archivos son los algoritmos y estructuras lógicas utilizadas para poder acceder a la información que tenemos en el disco. Cada uno de los sistemas operativos crea estas estructuras y logaritmos de diferente manera independientemente del hardware.

Cada sistema operativo maneja un único sistema de archivos, es decir Windows utiliza un sistema de archivos distinto al de Mac o al de Linux.

HFS. HFS es el Sistema de Archivo de Mac. Se usa en todo tipo de medio de almacenamiento, desde CD’s y DVD’s hasta el Disco Duro.

HFS+. HFS+ es la variante moderna de HFS con soporte para una mayor capacidad de almacenamiento, unicode y mucho más.

ISO9660

El más común de los Sistemas de Archivo en todos los CDs y DVDs es el Sistema de Archivo ISO9660.

Pero también es el más antiguo, y tiene algunas desventajas, tales como:

a) La estructura de carpetas solamente puede ser de 8 niveles de profundidad.

b)   Solamente usa nombres de archivo ‘cortos’

Joliet

Es un standar de Sistema de Archivo para CD.

Es una ampliación del antiguo ISO9660.  Está construido de la misma forma, pero con algunos cambios.

Los archivos y carpetas (directorios) pueden tener nombres largos.
La máxima jerarquía de profundidad de carpeta puede exceder los 8 Niveles.

Este Sistema de Archivo es muy popular, y el 99% de todos los CD’s y DVD’s lo contienen.

Fat 12:

Es el sistema de archivos de DOS, y es con el que formateamos los disquetes. Fue muy utilizado en las primeras PCs.

Fat 16:

Este sistema de archivos tenia muchas limitaciones, por ejemplo si el disco duro era mayor de 2 GB, era imposible particionar y no usaba nombre largos en los archivos, solo 8 caracteres.

Fat 32:

Fue utilizado a partir de 1997, y pudo ser utilizado en Windows 98, pero a medida que el tamaño de los discos duros se incrementaba, surgieron nuevas limitaciones. Se llamo Fat32, por que utiliza números de 32 bits para representar a los clusters en lugar de los 16 en los sistemas anteriores.

NTFS:

(New Technology File System) es un sistema de archivos diseñado específicamente para Windows NT (incluyendo las versiones Windows 2000, Windows 2003, Windows XP y Windows Vista), con el objetivo de crear un sistema de archivos eficiente, robusto con seguridad incorporada desde su base y eficacia para servidores y otras aplicaciones en red. No tiene limitaciones de tamaño clusters y en general en el disco. Una ventaja de este sistema de archivos es que tiene un sistema antifragmentación.

Es un sistema adecuado para las particiones de gran tamaño requeridas en estaciones de trabajo de alto rendimiento y servidores.

Los inconvenientes que plantea son:

• Necesita para sí mismo una buena cantidad de espacio en disco duro, por lo que no es recomendable su uso en discos con menos de 400 MB libres.
• No es compatible con MS-DOS, Windows 95, Windows 98 ni Windows ME.
• No puede ser utilizado en disquetes.

Este sistema de archivos posee un funcionamiento prácticamente secreto, ya que Microsoft no ha liberado su código como hizo con FAT. Gracias a la ingeniería inversa, GNU/Linux tiene soporte parcial de escritura y total de lectura en particiones NTFS. Existen varias alternativas, como Captive-NTFS que usa las librerías propietarias de Windows NT para tener acceso completo a NTFS, o NTFS-3G. A Mayo del 2007, NTFS-3g ya es una versión definitiva, y han sido incorporados por múltiples distribuciones como Ubuntu, Gentoo, Debian, openSUSE, Mandriva, Fedora, sólo por mencionar algunas.

LINUX:

Los sistemas de archivos más utilizados en Linux son: Ext3, ReiserFS, JFS y XFS.

ReiserFS es un sistema de archivos de propósito general, diseñado e implementado por un equipo de la empresa Namesys, liderado por Hans Reiser. Actualmente es soportado por Linux y existen planes de futuro para incluirlo en otros sistemas operativos. También es soportado bajo windows (de forma no oficial), aunque por el momento de manera inestable y rudimentaria (ReiserFS bajo windows). A partir de la versión 2.4.1 del núcleo de Linux, ReiserFS se convirtió en el primer sistema de ficheros con journal en ser incluido en el núcleo estándar. También es el sistema de archivos por defecto en varias distribuciones, como SuSE (excepto en openSuSE 10.2 que su formato por defecto es ext3), Xandros, Yoper, Linspire, Kurumin Linux, FTOSX, Libranet y Knoppix.

El Ext4 para Linux

“Ext4 es la evolución del sistema de archivos más utilizado en el mundo Linux, Ext3. En muchos sentidos Ext4 es una mejora más profunda de Ext3 que la que Ext3 fue de Ext2. Ext3 consistió básicamente en añadir journaling, pero Ext4 modifica ciertas estructuras críticas del sistema de archivos, como las destinadas a almacenar los datos de los archivos”.

cito en Wikipedia: http://es.wikipedia.org/wiki/Ext4

ext4 (fourth extended filesystem o “cuarto sistema de archivos extendido”) es un sistema de archivos con registro por diario (en inglés Journaling), anunciado el 10 de octubre de 2006 por Andrew Morton, como una mejora compatible de ext3. El 25 de diciembre de 2008 se publicó el kernel de Linux 2.6.28, que elimina ya la etiqueta de “experimental” de código de ext4.

Las principales mejoras son:

• Soporte de volúmenes de hasta 1024 PiB.
• Soporte añadido de extent.
• Menor uso del CPU.
• Mejoras en la velocidad de lectura y escritura.

]]> http://putolinux.wordpress.com/2008/11/26/como-formatear-una-puta-memora-usb-en-fat16/ Wed, 26 Nov 2008 16:48:08 +0000 pragmart http://putolinux.wordpress.com/2008/11/26/como-formatear-una-puta-memora-usb-en-fat16/ http://guiodic.wordpress.com/2008/09/11/guida-per-principianti-a-gnulinux-fstab-e-i-suoi-segreti/ Thu, 11 Sep 2008 09:00:06 +0000 guiodic http://guiodic.wordpress.com/2008/09/11/guida-per-principianti-a-gnulinux-fstab-e-i-suoi-segreti/ http://guiodic.wordpress.com/2008/09/01/guida-per-principianti-a-gnulinux-montare-hard-disk-e-pennette-flash/ Mon, 01 Sep 2008 16:30:25 +0000 guiodic http://guiodic.wordpress.com/2008/09/01/guida-per-principianti-a-gnulinux-montare-hard-disk-e-pennette-flash/ http://commitsuicide.wordpress.com/2008/08/26/shell-fat-laufwerksbezeichnung-andern/ Tue, 26 Aug 2008 08:06:02 +0000 Chris http://commitsuicide.wordpress.com/2008/08/26/shell-fat-laufwerksbezeichnung-andern/

Wer hätte das gedacht, dass es nochmal interessant sein könnte eine Laufwerksbezeichnung zu ändern?
Normalerweise bekommen Festplatten oder sowas bei mir keinen Namen, mir reichen die Einhängepunkte in meinem System…

Aber da ich gestern einen neuen USB-Stick bekommen habe, der eine total kryptische Volumen-Bezeichnung hatte, und dieser entsprechend bei mir auch nach /media/A2G8EWASWEISSICH gemountet wird, wollte ich das Label schon ändern. Oder habt ihr immer Lust den ganzen Namen zum Navigieren in die Adressleiste der Nautilus oder der Shell einzugeben?

Nur: Wie ändert man unter Linux die Datenträgerbezeichnung? Rechtsklick -> Eigenschaften wie bei Windows geht nicht!
Für (v)FAT-formatierte Laufwerke kann man das dennoch recht simpel über die Bash erledigen! Man braucht lediglich die mtools, die wir mit sudo apt-get install mtools in unserem Ubuntu ganz schnell installiert haben.
Anschließend benennen wir unseren Stick ganz einfach um:
sudo mlabel -i /dev/sdb1 ::"stick"

Und Tada: Der Stick wird beim nächsten Einhängen nach /media/STICK gemountet!

I just want to wrap up how I managed to recover the data from a laptop’s damaged hard disk drive. The 40GB disk was formatted with FAT32, had a Windows XP and some serious I/O error problems preventing it from booting.

I cleaned up my external 80 GB HDD, plugged it via USB into the laptop and booted the system with the latest Knoppix-CD. I reformatted the entire disk (/dev/sda1) with the ext3 file system, mounted it with (# mkdir /media/sda1 ; mount -t auto /dev/sda1 /media/sda1) and gave full access to the entire disk (# cd /media/sda1 ; chmod 777 *).

Since Knoppix is missing the dd_rhelp script, I downloaded the latest package and put it on that external disk (into /media/sda1/dd_rhelp). The damaged disk in the laptop was /dev/hda1. I set disk-access parameters for that disk back to basic but safe, disabling DMA and higher level PIO mode access:
# hdparm -m 0 -d 0 -p 0 -A 0 -X 08 /dev/hda
This makes things horribly slow in copying the large chunks of good data, but it improved the overall process since it can handle bad blocks in a better fashion. Next, I edited the dd_rhelp script and set the values “max_bs=1024″ and “min_bs=64″ in /media/sda1/dd_rhelp/dd_rhelp. The standard values of dd_rhelp are fine, but slow down the copying of data if the disk is damaged to a larger degree.

Ready to copy the data. Change to root with “su” and then run
# /media/sda1/dd_rhelp/dd_rhelp /dev/sda1 /media/sda1/sda1_backup.img
This process makes a bit-per-bit copy of the entire disk and writes it to the image sda1_backup.img. Any bit that cannot be read by the program will be zero. This takes a while. Quite a while. For my 40GB about a week. Which had nothing to do with the hdparm above but with the overall state of the disk (I ran the process twice). You may kill the dd_rhelp and the dd_rescue processes at any time and continue later on. dd_rhelp writes a log file that keeps track of the overall progress that has been made.

When you are done make a copy of the rescued image /media/sda1/sda1_backup.img and get yourself another hard drive that is at least as big as the image you just rescued or make some space on another hard drive. You will have to create a new FAT32 partition that is at least as big as the image. If the file system of the disk from where you just rescued the data has file system X, create a new X partition of that size. In my case, that new partition mounted as /media/sdb6. Now, copy the data from the image to that partition with
# dd if=/media/sda1/sda1_backup.img of=/dev/sdb6
Mounted /dev/sdb6 and saw the data. You can now run any file system/data/rescue operations on that disk (or the image file) or copy what’s left of it.

Update: compiled some data in a How To: Recover Windows Partitions.

Yes, this is my first attempt of creating a list of useful, everyday bash commands – as I find myself constantly in the situation looking for a specific bash command. If you’re unlucky, googleing the right command (especially if you don’t know what it’s called) can cost you several minutes if not hours.

So this will save me and hopefully you as well, the next time plenty of time. If you think there’s an important command still missing, which is more than likely, feel free to leave a comment with the command and a short explanation what it does.

Very special thanks to Bernd for the idea and his input! Thank you!

Basics:

cp test.txt /home/user/Desktop copies a txt file called test to the user’s Desktop

mv /home/test.txt /home/user/Desktop/ moves a txt file called test from the user’s home directory to the Desktop

sudo chmod -R 755 * changes the user rights recursively for the owner to read, write and execute – for group and world to read and execute. (this command requires root rights «sudo»)

sudo chmod -R u+w /home/user/data changes the user rights for the owner recursively to write and read of the directory /home/user/data

echo $USER prints the currently being used user name

sudo chown -R $USER.users ~/.kde/share/apps/kmail/mail changes the user ownership of the directory ~/.kde/share/apps/kmail/mail to the currently being used user name

ls -la ~/.kde/share/apps/ lists the content of a directory e.g ~/kde/share/apps/

ls | wc -l counts the files in a directory

cp test.txt{.bkp} copies text.txt to text.txt.bkp (creates a backup)

uname -a or uname -a | awk '{print $3}' lists your current kernel version number (awk ‘{print $3} prints only the kernel version, without its description)

Going deep:

perl -pi.bak -e 's/search/replace/' *.php replaces in all .php files the word “search” with “replace” and creates a backup file .bak e.g. index.php to index.php.bak

grep --color ; displays the search result in colour

grep -r searches /home/ searches recursively in /home/

pgrep firefox displays the process ID number of firefox or any application. useful to «kill» a process

sudo kill -9 pid pid = processID number ….. kill -9 kills the process (requires root rights)

sudo /etc/init.d/networking restart restarts the networking service

Mounting:

sudo mkdir hda1 creates a directory called “hda1″

sudo mount /dev/hda1 /mnt/hda1 mounts the harddisk hda1 into the directory /mnt/hda1

sudo umount /dev/sdb5 unmounts a device «sdb5» (in this case usb device)

sudo mount -t ntfs-3g /dev/hda5 /mnt/windows -o locale=de_DE.utf8 mounts a NTFS formatted harddisk read and writeable into /mnt/windows (this implies that the packages «ntfs-3g» & «ntfs-config» are installed)

sudo mount -t vfat /dev/hda1 /mnt/windows_c mounts a FAT formatted harddisk read and writeable into /mnt/windows_c

sudo blkid shows UUID number of a device

mount lists mounted devices

lsusb lists usb devices

sudo fdisk -l lists all mounted and unmounted harddisks or partitions

fuser -v /mount/point displays why a device can’t be unmounted and which process/user uses the device

Misc:

update-alternatives --config editor let’s you change the standard terminal editor (e.g from vim to nano)

ls -la /etc/alternatives/javac lists all java compilers

java -version displays the currently installed java version

msgfmt test.po -o test.mo compiles a language translation file (po) into a binary .mo file …. -o stands for output

sudo aptitude install language-pack-gnome-de installs a package from a repository (e.g. german gnome language pack)

sudo aptitude install tree installs a package called «tree»

tree -d -i (-i removes the 'tree') lists directories and subdirectories…
tree -d -i > dir.txt lists directories and subdirectories and saves the content into dir.txt

aptitude show ktorrent shows information on ktorrent and lists where it’s available (which repository)

MPLAYER:
mplayer -dumpstream "mms://a1505.v16544e.c16544.g.vm.akamaistream.net/7/1505/16544/v001/roomediaco1.download.akamai.com/16544/wm.roomedia/streamingVX/17056/1386/laptop_300.wmv?clipId=1386_computing_0030&channel=Netevents+TV&category=netevents+tv&site=vnudotnet%2fcomputing" -dumpfile laptop.wmv downloads a stream and saves it as «laptop.wmv»

When I tried to mount vfat partition (fat32 for windows) I got an error like “unknown filesystem type ‘vfat’ ” or something like it.

When I searched for a solution I found that the vfat module is exist in fedora 7 but not loaded to the kernal and I don’t know why.

so I list the modules that I have:
#su -
#lsmod
and I saw vfat

Then I loaded vfat module into the kernal:
#modprobe moduleName
or
#insmod (path to module starting from /lib/modules/(yourKernel)/ModuleName

after this I mounted vfat partition and it rocks

Nota ai nuovi arrivati: Il procedimento qui descritto non risolve una beneamata mazza. Comprate un nuovo lettore (io l’ho fatto), sorry. )

Ho comperato presso un grande magazzino della mia città questo lettore MP3 – mi hanno invogliato:

1. il prezzo competitivo;
2. il fatto che, a differenza degli altri lettori della serie GoGear, non usano il protocollo MTP per la comunicazione dei dati, ma la normale specifica USB storage

Dopo un certo numero di giorni, ho notato una degradazione nei tempi di riconoscimento della periferica da parte dei miei PC, e ho pensato fosse il caso di fare una bella riformattata – salvo scoprire, dopo aver cancellato la partizione, averne ricreata un’altra e averla formattata, che detta non era accessibile (il messaggio d’errore era Bad superblock).

Non volendomi rassegnare (e non volendo tornare a usare Winzozz solo per far rifunzionare l’aggeggio), ho fatto dei tentativi, e ho trovato una combinazione tipo di partizione/filesystem che sembra andare bene:

1. Tipo di partizione: FAT16 (codice esadecimale: 06)
2. Filesystem: FAT16, con dimensione di ogni settore logico pari a 2048 byte. Il filesystem è stato creato con

   mkfs.vfat -F 16 -S 2048  /dev/[periferica, così come è stata riconosciuta dal kernel)

A parte un piccolo problema estetico (la quantità di spazio su disco massima rilevata è pari a 3 gigabytes, invece dell’1 gigabyte previsto dal mio lettore O_o), tutto sembra andare bene.