LTOOLS: accedi ai file Linux da Windows 9x/ME/NT/2000/XP

di Werner Zimmermann ( wernerzimmermann.name )

Original source: http://wernerzimmermann.name/media/files/ltools.html

Gli LTOOLS forniscono sotto Windows una funzionalità simile a quella degli MTOOLS sotto Linux: ti consentono di accedere ai tuoi file sull'”altro” sistema operativo.

Linux Journal con LTOOLS.

Rivista per gli utenti Linux .

Utilizzo di LTOOLS dalla riga di comando

Il cuore di LTOOLS è un insieme di programmi a riga di comando, che possono essere richiamati da DOS o da una finestra DOS in Windows 9x/ME o Windows NT/2000/XP. Forniscono le stesse funzionalità dei noti comandi LINUX ‘ls’, ‘cp’, ‘rm’, ‘chmod’, ‘chown’ e ‘ln’. Quindi, sotto DOS/Windows è possibile

• elenca file e directory Linux (comando: ldir),
• copiare file da Linux a Windows e viceversa (comandi: lread, lwrite),
• eliminare o rinominare file Linux (comandi: ldel, lren),
• creare collegamenti simbolici (comando: lln),
• creare nuove directory Linux (comando: lmkdir),
• modificare i diritti di accesso e il proprietario di un file Linux (comando: lchange),
• cambiare la directory predefinita di Linux (comando: lcd),
• imposta l’unità predefinita di Linux (comando: ldrive) e
• mostra la configurazione della partizione del disco rigido (comando: ldir -part).

Come con molti strumenti UNIX, queste funzioni sono incluse in un singolo eseguibile, che viene richiamato con un insieme di parametri della riga di comando. Per semplificarti la vita, viene fornita una serie di file batch (script di shell), in modo che non sia necessario ricordare e digitare tutti questi parametri.

Inoltre esiste una versione Unix/Linux di LTOOLS, in modo che tu possa usarli sotto Solaris o anche sotto Linux, quando vuoi accedere a un file su un’altra partizione del disco rigido senza montare questa partizione.

LTOOLgui – una GUI Java per LTOOLS

I programmi a riga di comando sono antiquati! Dov’è l’interfaccia utente grafica di LTOOLS? Bene, nessun problema: usa LTOOLgui. LTOOLgui, scritto in Java utilizzando la libreria Swing di JDK 2, fornisce un’interfaccia utente simile a Windows Explorer (Fig. 1). In due sotto-finestre LTOOLgui mostra gli alberi delle directory DOS/Windows e Linux. La navigazione può essere eseguita con le consuete azioni punta e clicca. La copia di file da Windows a Linux o viceversa può essere eseguita tramite copia e incolla o trascina e rilascia. Facendo clic con il pulsante destro del mouse si aprirà una finestra di dialogo per visualizzare e modificare gli attributi del file come diritti di accesso, GID o UID. Facendo doppio clic su un file verrà avviato, se si tratta di un eseguibile di Windows, o lo si aprirà con l’applicazione associata. Funziona anche con i file Linux, se hanno un’applicazione Windows registrata.

A proposito: puoi anche usare LTOOLgui come file manager sotto Linux. Poiché i programmi a riga di comando LTOOLS sono disponibili anche in una versione Linux, è possibile accedere ai file sui dischi, senza montarli.

L’autore ha scelto Java per LTOOLgui, perché Java è particolarmente adatto per l’accesso di basso livello al disco rigido… sto scherzando! No, ovviamente questo non è affatto possibile in Java. Se desideri accedere direttamente all’hardware, devi utilizzare il codice C++ e JNI (Java to Native Interface). Tuttavia, poiché JNI funziona solo con codice a 32 bit, in Windows 9x/ME ciò significherebbe utilizzare il “thunk da 32 bit a 16 bit” (vedere di seguito). Poiché all’autore non piaceva l’idea di combinare Java di Sun con il codice MASM di Microsoft, adottò un altro approccio. Utilizza semplicemente il programma a riga di comando LTOOLS, che viene chiamato da Java tramite la nota interfaccia stdin/stdout. Quindi, per il lato Java, l’accesso hardware significa un semplice I/O di file basato sul flusso.

Fig. 1: Interfaccia utente grafica LTOOLgui basata su Java

Accesso ai file su Internet?

Senza dubbio, qualsiasi programma all’avanguardia deve essere consapevole di Internet! Bene, se esegui LREADjav su un computer remoto e ti connetti ad esso tramite il pulsante di connessione di LTOOLgui, puoi accedere ai file Linux su questo server remoto come se fossero locali. LREADjav è un semplice demone server, che traduce la richiesta, emessa da LTOOLgui su TCP/IP, in chiamate di programmi a riga di comando LTOOLS e invia l’output dei programmi a riga di comando tramite TCP/IP a LTOOLgui (Fig. 2). Naturalmente, non solo puoi visualizzare gli elenchi delle directory, ma puoi fare tutto da remoto, cosa puoi fare localmente, incluso caricare e scaricare file. La macchina remota può eseguire Unix/Linux o Windows. Oggi questo è più un giocattolo che un’applicazione seria, perché LREADjav può porre problemi di sicurezza. Nella configurazione predefinita, può essere utilizzato solo da ‘localhost’, ma può essere configurato per consentire connessioni da 3 diversi client remoti. Ma vengono identificati solo tramite il loro indirizzo IP, non esiste alcuna protezione tramite password o simili. Tuttavia, se un utente ha un’applicazione seria per questo, può facilmente implementare uno schema login/password… È tutto Open Source!

Fig. 2: LTOOLgui per l’accesso remoto

Niente Java? Usa il tuo browser web!

Forse non hai Java 2 installato. Bene, nessun problema, purché tu abbia un browser web. Avvia ‘LREADsrv’ e il tuo browser web e come URL digita ‘http://localhost’ (Fig. 3). Ora l’elenco delle directory Linux dovrebbe essere visualizzato graficamente nel tuo browser web. LREADsrv è un piccolo server web locale, che tramite una semplice interfaccia simile a CGI rende LTOOLS accessibile tramite richieste HTTP e converte il loro output dinamicamente in pagine HTML (Fig. 4). Naturalmente questo non fornisce solo l’accesso locale, ma consente anche l’accesso remoto tramite Internet. Tuttavia, per gli utenti remoti LREADsrv ha lo stesso basso livello di sicurezza di LREADjav.

Poiché LREADsrv è basato su moduli HTML, che ad esempio non supportano il drag-and-drop o il copia-e-incolla diretto, lavorare con il browser web è un po’ meno conveniente che lavorare con la GUI basata su Java. Tuttavia fornisce le stesse funzionalità.

Fig. 3: Utilizzo di un browser web per esplorare i file Linux

Fig. 4: LREADsrv – Accesso basato su HTTP ai file Linux

Componenti interni LTOOLS: accesso al disco rigido in Windows

Poiché DOS/Windows stesso non supporta interfacce con filesystem esterni, LTOOLS deve accedere ai byte di dati “grezzi” direttamente sul disco. Per comprendere i meccanismi interni di LTOOLS, è necessario avere una conoscenza di base delle seguenti aree:

• Come sono organizzati i dischi rigidi in partizioni e settori e come è possibile accedervi, ovvero come i byte “grezzi” possono essere letti o scritti dal disco. Queste informazioni si trovano ad esempio in /2,3/.
• Come è organizzato il filesystem Extended 2 di Linux. Una buona panoramica su tutti gli inode, i gruppi, i blocchi, le bitmap e le directory può essere trovata ad esempio in /4/.

Ciò porta automaticamente ad un’architettura a strati del kernel LTOOLS (Fig. 5), che consiste di diversi file C:

• Il livello più basso 1 (nel file Readdisk.c) accede fisicamente al disco rigido. Questo livello si occupa (quasi tutte) delle differenze tra DOS, Windows 9x/ME, Windows NT/2000/XP e Linux/Unix riguardo all’accesso diretto al disco rigido e cerca di nasconderle agli strati superiori. Ne parleremo presto.
• Il livello 2 si occupa delle tipiche strutture di inode, blocchi e gruppi UNIX in cui è organizzato il filesystem Extended 2.
• Il livello 3 gestisce la struttura delle directory del filesystem.
• Il livello 4 più alto (in Main.c) fornisce l’interfaccia utente ed esegue la scansione dei parametri della riga di comando.

Eseguendo la scansione della tabella delle partizioni del tuo disco rigido, LTOOLS tenta di trovare automaticamente la tua prima partizione Linux sul tuo primo disco rigido. Se vuoi accedere ad un’altra partizione o disco, devi specificarlo tramite il parametro della riga di comando ‘-s’, ad esempio ‘-s/dev/hdb2’. In alternativa è possibile impostare un’altra unità e partizione predefinite tramite il comando ‘ldrive’. Per scoprire quali partizioni hai, chiama ‘ldir -part’.

Fig. 5: Architettura a strati di LTOOLS

La vita era facile ai bei vecchi tempi del DOS. C’era solo un modo per accedere in lettura o scrittura a basso livello al disco rigido: interruzione del BIOS 13h /3/. Le strutture dati del BIOS limitavano i dischi rigidi a 1024 cilindri, 63 testine e 255 settori da 512 byte, ovvero 8 GB. La maggior parte dei compilatori C forniva una funzione denominata biosdisk(), in modo che questa funzione potesse essere utilizzata direttamente senza dover scrivere codice in linguaggio assembly. Per gestire i dischi rigidi più grandi, alcuni anni fa furono introdotte le funzioni int 13h ‘estese’. Per superare le limitazioni del BIOS, queste funzioni utilizzano uno schema di indirizzamento lineare, indirizzi a blocchi logici (LBA), anziché il vecchio indirizzamento del settore della testata (CHS).

Funziona ancora nella finestra DOS di Windows 9x/ME (Tabella 1), almeno per l’accesso in lettura e finché il programma è compilato con un compilatore a 16 bit. (Gli LTOOLS utilizzano Borland C, la versione Windows NT/2000/XP compila anche con Microsoft Visual C, la versione Unix/Linux utilizza GNU C). Se desideri un accesso in scrittura di basso livello, hai bisogno dei “blocchi del volume” /3/. Questo meccanismo informa il sistema operativo che il tuo programma sta eseguendo scritture dirette sul disco ignorando i driver del sistema operativo, in modo che Windows possa impedire ad altri programmi di accedere al disco finché non hai finito. Ancora una volta questo può essere fatto senza programmazione in assembly utilizzando la funzione ioctl() del compilatore C.

In un programma Windows a 16 bit le funzioni del BIOS possono essere richiamate solo tramite DPMI. Poiché la maggior parte dei compilatori C non fornisce funzioni wrapper, ciò richiederebbe un assemblatore (inline). Tuttavia, Win16 non consente affatto i programmi da riga di comando, quindi non preoccuparti…

Nella finestra DOS di Windows NT/2000/XP, l’utilizzo del BIOS int 13h porterà a un GPF (General Protection Fault). Per motivi di sicurezza, Windows NT/2000/XP non consente l’accesso diretto al disco rigido bypassando il sistema operativo. Tuttavia, Microsoft fornisce una soluzione che è quasi altrettanto semplice di quella che scriveresti sotto Unix/Linux: int disk_fd = open(“/dev/hda1”, O_RDWR);

Questo aprirà la partizione del tuo disco rigido /dev/hda1, per leggere chiamerai read(), per scrivere chiamerai write(). Semplice e diretto, non è vero? Sotto Windows NT/2000/XP, se si utilizza l’API WIN32 /5/, la funzione CreateFile() non solo consente di creare e aprire file, ma anche partizioni del disco: HANDLE hPhysicalDrive = CreateFile(“\\\\.\\PhysicalDrive0”, GENERICO_LETTURA | GENERIC_WRITE, FILE_CONDIVIDI_READ | FILE_SHARE_WRITE, 0, APERTO_ESISTENTE, 0, 0 );

La lettura e la scrittura dei settori del disco ora possono essere eseguite tramite ReadFile() e WriteFile().

Per un momento potresti pensare che potresti usare la stessa funzione Win32 sotto Windows 9x/ME. Tuttavia, se continui a leggere la documentazione di CreateFile(), troverai: Windows 95: questa tecnica non funziona per l’apertura di un’unità logica. In In Windows 95, se si specifica una stringa in questo formato, verrà restituito CreateFile un errore.

Sotto Windows 9x/ME la documentazione Win32 di Microsoft consiglia di chiamare BIOS Int 13h tramite VWIN32, uno dei VxD del sistema (driver del kernel). Se provi a farlo, però, non ci riuscirai. Il rapporto sul problema Q137176 nella Knowledge Base di Microsoft afferma che, nonostante ciò che dice la documentazione ufficiale di Win32, questo funziona solo per i dischi floppy, non per i dischi rigidi. Come dice il rapporto del problema, per i dischi rigidi l’unico modo è chiamare BIOS Int 16h in codice a 16 bit. Per chiamare codice a 16 bit da un programma a 32 bit, è necessario il “thunk da 32 bit a 16 bit” di Microsoft… Questa non è solo un’altra API (con altre funzionalità non documentate o bug documentati?), il thunk richiede anche il compilatore thunk di Microsoft, che da uno script di definizione genera codice assembler. Da ciò è necessario generare un file oggetto a 16 bit e uno a 32 bit utilizzando l’assembler MASM di Microsoft. Questi saranno collegati con alcune decine di righe di codice C, che dovrai scrivere, risultando in una DLL (libreria di collegamento dinamico) a 16 bit e 32 bit. A proposito, per questo non hai bisogno solo di Visual C++ a 32 bit, ma devi anche avere una vecchia versione a 16 bit del compilatore C di Microsoft… Capito? Utilizzare un insieme di strumenti proprietari e non ampiamente utilizzati non sarebbe una buona soluzione per uno strumento software Open Source come LTOOLS!

Riepilogo: devono esserci versioni separate per DOS/Windows 9x/ME, Windows NT/2000/XP e Linux/Unix. Per nasconderlo il più possibile all’utente, LTOOLS cerca di scoprire sotto quale sistema operativo è in esecuzione e richiama automaticamente l’eseguibile appropriato.

Tabella 1: accesso al disco rigido di basso livello

Problemi di sicurezza?

Sì, avere LTOOLS in una certa misura può porre problemi di sicurezza. Ogni utente, che può eseguirli, può accedere e modificare i file sul filesystem LINUX, ad esempio cambiare i diritti di accesso ai file oi proprietari dei file, scambiare password sui file ecc. Tuttavia, questo è possibile anche con un semplice editor di dischi. Forse è solo un po’ più comodo quando si usa LTOOLS. Tuttavia, l’accesso illimitato è possibile solo se si utilizza DOS o Windows 9x/ME. In Windows NT/2000/XP l’utente LTOOLS deve disporre dei diritti di amministratore per accedere direttamente al disco rigido. Sotto Unix/Linux, nella maggior parte delle installazioni standard, solo l’amministratore di sistema ha diritti di accesso per i dispositivi disco ‘grezzi’ /dev/hda, /dev/hda1, ecc..

Ci sono alternative?

Gli LTOOLS non sono l’unica soluzione per accedere ai file Linux da DOS/Windows. Probabilmente Ext2tool /6/ di Claus Tondering, un insieme di strumenti a riga di comando, sviluppato nel 1996, è stata la prima soluzione a questo problema. Tuttavia, Ext2tool è limitato all’accesso in sola lettura e non viene eseguito in Windows NT. Basandosi su Ext2tool, Peter Joot nel 1997 scrisse una versione per Windows NT, ancora limitata alla sola lettura /7/. Entrambi i programmi sono stati scritti in C, i codici sorgente sono disponibili.

John Newbigin ci fornisce Explore2fs /8/, che viene fornito con una GUI molto carina e funziona sotto Windows 9x e Windows NT. Con l’accesso in lettura e scrittura fornisce le stesse funzionalità di LTOOLgui. A proposito: John ha fatto un ottimo lavoro, perché è riuscito a implementare il thunk da 32 bit a 16 bit di Microsoft (vedi sopra) anche sotto Delphi di Borland! Come tutti i programmi Delphi, Explore2fs si integra perfettamente in Windows, ma il porting su sistemi operativi non Windows potrebbe essere difficile.

Storia e futuro

La prima versione di LTOOLS è stata creata con il nome originale ‘lread’ da Jason Hunter e David Lutz presso la Willamette University, Salem/Oregon (USA). Questa prima versione funzionava sotto DOS, poteva mostrare elenchi di directory Linux e copiare file da Linux a DOS ed era limitata a piccoli dischi rigidi IDE e LINUX su partizioni primarie.

L’autore si è assunto la responsabilità della manutenzione e dell’ulteriore sviluppo nel 1996. Da allora, gli LTOOLS hanno imparato a gestire dischi rigidi più grandi, ad accedere a unità SCSI, a funzionare sotto Windows 9x/ME e Windows NT/2000/XP, ad ulteriori accessi in scrittura e sono stati riportati a UNIX, per farli funzionare sotto Solaris e Linux stesso. Hanno ottenuto un browser web basato e un’interfaccia utente grafica basata su JAVA ecc. Ecc. Molti utenti Linux, la maggior parte dei quali menzionati nel codice sorgente, hanno aiutato nei test e nel debug. Grazie.

Nel frattempo LTOOLS ha raggiunto la versione V4.7 /1/, forse anche di più, quando verrà pubblicato questo articolo. Oltre alle funzionalità aggiuntive, sono stati corretti molti bug e molto probabilmente ne sono stati introdotti di nuovi. Nel corso degli anni è rimasto un problema comune: nessuno aveva previsto la rapida velocità della tecnologia dei dischi rigidi, dove le dimensioni dei dischi sono esplose, raggiungendo permanentemente i limiti del sistema operativo. Ricordi i problemi del DOS con i dischi da 512MB, i problemi di Windows 3.x con le partizioni da 2GB, il limite del BIOS a 8GB ed i vari problemi che Windows NT ha a 2GB, 4GB e 8GB? È solo un momento fa! E comunque, anche Linux ha il suo problema: nei kernel precedenti alla 2.3, nessun file può superare i 2 GB, poiché Linux, come la maggior parte dei sistemi Unix a 32 bit, utilizza un puntatore di offset a 32 bit con segno in read() o write() (questo verrà risolto nel kernel 2.4 modificando gli offset su valori a 64 bit, ma il mantenimento della compatibilità verso l’alto potrebbe portare Linux agli stessi problemi discussi sopra per Windows). La standardizzazione del software per l’accesso al disco è sempre stata molto più lenta rispetto agli sviluppatori del disco, quindi hanno inventato soluzioni proprietarie per superare i limiti del sistema operativo. E sempre LTOOLS – e molti altri programmatori – hanno dovuto occuparsene … Quindi non arrabbiarti se LTOOLS non funziona per te sul tuo nuovissimo disco da 64 GB. È Open Source, quindi prova semplicemente ad aiutare a eseguirne il debug e svilupparli ulteriormente!

E non dimenticare, se usi LTOOLS: fallo a tuo rischio e pericolo! L’accesso in sola lettura a Linux non è critico. Tuttavia, se utilizzi l’accesso in scrittura per eliminare file o modificare attributi di file sul tuo disco Linux, LTOOLS – e tu come utente – puoi creare molte sciocchezze. Quindi tieni sempre un backup!

Riferimenti

1. Michael Tischer: PC-Intern 4. Data-Becker-Verlag
2. http://www.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files.html Elenco di interruzioni di Ralf Brown per PC x86
3. http://metalab.unc.edu/pub/Linux/system/filesystems/ext2/Ext2fs-overview-0.1.ps.gz: panoramica di Gadi Oxman sul filesystem Extended 2.
4. API Win32 di Microsoft Windows: documentazione fornita con la maggior parte dei compilatori Windows C o sui CD MSDN
5. http://metalab.unc.edu/pub/Linux/system/filesystems/ext2/ext2tool_1_1.zip: Ext2tool di Claus Tondering
6. http://metalab.unc.edu/pub/micro/pc-stuff/Linux/utils/dos/ext2nt.lsm: Ext2nt di Peeter Joot
7. http://uranus.it.swin.edu.au/~jn/linux/explore2fs.htm: Explore2fs di John Newbigin

Circa l’autore

“Nella vita reale” Werner Zimmermann insegna ingegneria di controllo, sistemi digitali e architettura dei computer alla Hochschule Esslingen – Università di Scienze Applicate, Esslingen, Germania. Ha un background hardware e software nei sistemi embedded automobilistici e industriali. La sua ‘carriera’ come sviluppatore di software per sistemi Linux è iniziata nel 1994, quando ha acquistato un lettore CDROM, che non era supportato da Linux… Così ha sviluppato ‘aztcd.c’, un driver CDROM Linux, che è ancora incluso in tutti kernel Linux standard, anche se l’unità ora è molto obsoleta.

Susan

I’ve always been captivated by the wonders of science, particularly the intricate workings of the human mind. With a degree in psychology under my belt, I’ve delved deep into the realms of cognition, behavior, and everything in between. Pouring over academic papers and research studies has become somewhat of a passion of mine – there’s just something exhilarating about uncovering new insights and perspectives.