LTOOLS – Få tilgang til Linux filer fra Windows 9x/ME og Windows NT/2000/XP

Original English version: http://www.it.fht-esslingen.de/~zimmerma/software/ltools/ltools.html

av Werner Zimmermann

De LTOOLS gi under Windows en lignende funksjonalitet som mtools gjøre under Linux: De lar deg få tilgang til filene dine på “fiendtlig” filsystem.


Bruke LTOOLS fra kommandolinjen

I hjertet av LTOOLS er et sett med kommandolinjeprogrammer, som kan kalles fra DOS eller fra en DOS-vindu i Windows 9x/ME eller Windows NT/2000/XP. De gi samme funksjonalitet som den kjente Linux-kommandoer ‘ls’, ‘cp’, ‘rm’, ‘chmod’, ‘chown’ og ‘ln’. Dermed under DOS/Windows kan du

  • Listen Linux filer og kataloger (kommando: ldir)
  • kopiere filer fra Linux til Windows og vice versa (kommandoer: lread, lwrite)
  • slette eller endre navn på Linux filer (kommandoer: ldel, lren),
  • opprette symbolske linker (kommando: LLN),
  • skape nye Linux-kataloger (kommando: lmkdir),
  • endre tilgangen rettigheter og eier en Linux fil (kommando: LEndre)
  • endre Linux standardkatalogen (kommando: lcd),
  • sette Linux standarddisken (kommando: ldrive) og
  • vise din harddisk partisjon oppsett (kommando: ldir -delen).

Som med mange UNIX-verktøy, er disse funksjonene innbefattet i en enkelt kjørbar, som kalles med en bunt av kommandoparametrene. For å gjøre livet ditt enklere, er et sett med batch-filer (shell scripts) forutsatt, slik at du ikke trenger å huske og skrive inn alle disse parameterne.

I tillegg er det et Unix/Linux-versjonen av LTOOLS, slik at du kan bruke dem under Solaris eller under Linux, når du vil ha tilgang til en fil på en annen harddisk partisjon uten monterings denne partisjonen.

LTOOLgui – en Java GUI for LTOOLS

Kommandolinjeprogrammer er gammeldags! Hvor er LTOOLS grafisk brukergrensesnitt? Vel, ikke noe problem: Bruk LTOOLgui. LTOOLgui skrevet i Java bruker JDK 2s Swing bibliotek, gir et Windows Utforsker lignende brukergrensesnitt (Fig. 1). I to sub-vinduer LTOOLgui viser DOS/Windows og Linux katalogtrær. Navigere kan gjøres ved de vanlige pek-og-klikk handlinger. Kopiere filer fra Windows til Linux eller omvendt kan gjøres ved å kopiere og lime inn eller dra-og-slipp. Ved å klikke på høyre museknapp vil åpne en dialog for å se og endre filattributter som tilgangsrettigheter, GID eller UID. Dobbeltklikke på en fil vil starte det, hvis det er en Windows kjørbar, eller åpne den med det tilknyttede programmet. Dette fungerer selv med Linux filer, hvis de har en registrert Windows-program.

BTW: Du kan også bruke LTOOLgui som filbehandler under Linux. Som LTOOLS kommandolinjeprogrammer kommer også i en Linux-versjon, og dermed kan du få tilgang til filer på harddisken, uten montering dem.

Forfatteren valgte Java for LTOOLgui, fordi Java er spesielt egnet for lavt nivå harddisk tilgang … bare tuller! Nei, selvfølgelig, dette er ikke mulig i Java i det hele tatt. Hvis du vil ha tilgang til maskinvaren direkte, må du bruke C ++ kode og JNI (Java til Native Interface). Men som JNI fungerer bare for 32bit kode, under Windows 9x/ME dette ville bety å bruke ’32bit til 16bit thunking’ (se nedenfor). Som forfatteren ikke liker ideen om å kombinere Suns Java med Microsofts MASM kode, tok han en annen tilnærming. Han bruker bare LTOOLS kommandolinje program, som blir kalles fra Java via den velkjente stdin/stdout- grensesnitt. Så for Java side, betyr hardware tilgang enkel strøm basert fil I/O.

FIG. 1: JAVA-BASERT LTOOLGUI GRAFISK BRUKERGRENSESNITT

Filtilgang over Internett?

Ingen tvil, må noen state of the art programmet være Internet klar! Vel, hvis du kjører LREADjav på en ekstern datamaskin, og du koble til den via LTOOLgui er tilkoblingsknappen, kan du få tilgang til Linux filer på denne ekstern server som om de var lokale. LREADjav er en enkel serverdaemon, som overs anmodning, utgitt av LTOOLgui over TCP/IP, inn LTOOLS kommandolinje program anrop og sender utgangen fra kommandolinje-programmer tilbake via TCP/IP til LTOOLgui (fig. 2). Selvfølgelig kan du ikke bare visning katalogoppføringer, men kan gjøre alt eksternt, hva du kan gjøre lokalt, inkludert opplasting og nedlasting. Den eksterne maskinen kan kjøre Unix/Linux eller Windows. I dag er dette mer som et leketøy enn en seriøs søknad, fordi LREADjav kan utgjøre sikkerhetsproblemer. I standardkonfigurasjonen, kan det bare brukes fra ‘localhost’, men den kan konfigureres til å tillate tilkoblinger fra 3 forskjellige fjerntliggende klienter. Men de er identifisert via deres IP-adresse, er det ingen passordbeskyttelse eller lignende. Men hvis en bruker har en seriøs søknad for det, han kan enkelt implementere et brukernavn/passord ordningen … Det er all Open Source!

FIG. 2: LTOOLGUI FOR FJERNAKSESS

Ingen Java? Bruk din nettleser!

Kanskje du ikke har Java 2 installert. Vel, ikke noe problem, så lenge du har en nettleser. Start ‘LREADsrv’ og din nettleser og som URL type ‘http: // localhost’ (Fig. 3). Nå Linux katalogoppføring skal vises grafisk i nettleseren din. LREADsrv er en liten lokal webserver, som via en enkel CGI-lignende grensesnitt gjør LTOOLS tilgjengelige via HTTP-forespørsler og omdanner deres utgangs dynamisk inn i HTML-sider (fig. 4). Selvfølgelig, dette betyr ikke bare gi lokal tilgang, men gir også fjerntilgang via Internett. Men for eksterne brukere LREADsrv har samme lave nivå av sikkerhet som LREADjav.

Fordi LREADsrv er basert på HTML-former, som for eksempel ikke støtter dra-og-slipp eller direkte kopi-og-lim, som arbeider med nettleseren er litt mindre praktisk enn å jobbe med Java-basert GUI. Likevel gir det de samme funksjonene.

FIG. 3: EXPLORING LINUX FILER MED MICROSOFTS INTERNET EXPLORER
FIG. 4: LREADSRV – HTTP BASERT TILGANG TIL LINUX FILER

LTOOLS Internals – Accessings Harddisk under Windows

Som DOS / Windows i seg selv ikke støtter grensesnitt til utenlandske filsystemer, må LTOOLS tilgang til “rå” databytene direkte på disken. For å forstå de innvendige av LTOOLS, må du ha en grunnleggende forståelse av følgende områder:

  • Hvordan harddisker er organisert i partisjoner og sektorer, og hvordan de kan nås, dvs. hvor “rå” byte kan leses eller skrives fra disk. Denne informasjonen kan bli funnet for eksempel i /2,3/.
  • Hvordan Linux Utvidet to filsystem er organisert. En god oversikt om alle inodes, grupper, blokker, bitmaps og kataloger ting kan finnes for eksempel i /4/.

Dette fører automatisk til en lagdelt arkitektur av LTOOLS kjernen (fig. 5), som består av flere filer C:

  • Det laveste lag 1 (i fil Readdisk.c) fysisk tilgang til harddisk. Dette laget avtaler med (nesten alle) forskjeller mellom DOS, Windows 9x/ME, Windows NT/2000/XP og Linux/Unix om direkte harddisk tilgang og prøver å skjule dem fra de høyere lag. Mer om det snart.
  • Layer 2 omhandler UNIX typisk inode, blokk og konsernstrukturer, der den utvidede to filsystem er organisert.
  • Layer 3 forvalter katalogstrukturen til filsystemet.
  • Den høyeste laget 4 (i main.c) inneholder brukergrensesnittet og skanner kommandolinjeparametrene.

Ved å skanne harddisken partisjonstabellen, de LTOOLS prøve å finne din første Linux partisjon på første harddisk automatisk. Hvis du vil ha tilgang til en annen partisjon eller disk, må du angi den ved kommandolinjeparameteren ‘-s’, f.eks ‘-s / dev / hdb2’. Alternativt kan du sette en annen standard stasjons og partisjon via kommando ‘ldrive’. For å finne ut, hvilke partisjoner du har, kaller ‘ldir -delen’.

FIG. 5: LTOOLS LAGDELT ARKITEKTUR

Livet var enkelt i de gode gamle dager med DOS. Det var bare en måte for lavt nivå lese eller skrive tilgang til harddisken din: BIOS avbryte 13t /3/. BIOS datastrukturer begrenset harddisker til 1024 sylindere, 63 hoder og 255 sektorer på 512 bytes, dvs. 8GB. De fleste C-kompilatorer gitt en funksjon som heter biosdisk (), slik at denne funksjonen kan brukes direkte uten å måtte kode i assembly. Å håndtere større harddiskene, noen år siden ‘utvidet’ INT 13h funksjoner ble innført. For å overvinne begrensningene BIOS, disse funksjonene bruke en lineær adresseringsopplegg, logiske blokkadresser (LBA), snarere enn den gamle sylinderhode-sektor (CHS) adressering.

Dette fungerer fortsatt i Windows 9x/ME er DOS-vindu (tabell 1), i hvert fall for lesetilgang og så lenge programmet er kompilert med en 16bit kompilatoren. (De LTOOLS bruke Borland C, Windows NT/2000/XP-versjonen også kompilerer med Microsoft Visual C, bruker Unix/Linux-versjon GNU C). Hvis du vil ha lavt nivå for å kunne skrive, må du ‘volum låser’ /3/. Denne mekanismen informerer operativsystemet, at programmet gir direkte disk skriver utenom operativsystemet drivere, slik at Windows kan unngå at andre programmer tilgang til disken før du er ferdig. Igjen kan dette gjøres uten montering programmering ved hjelp av C-kompilatoren ioctl () -funksjonen.

I en 16bit Windows program BIOS-funksjoner som bare kan kalles via DPMI. Som de fleste C-kompilatorer ikke gir wrapper funksjoner, ville dette kreve (inline) assembler. Men Win16 ikke tillate kommandolinjeprogrammer i det hele tatt, så ikke bekymre deg …

I Windows NT/2000/XP DOS boks, vil bruke BIOS int 13h føre til en GPF (generell beskyttelsesfeil). På grunn av sikkerhetsmessige årsaker, ikke Windows NT/2000/XP ikke tillater direkte harddisk tilgang utenom operativsystemet. Imidlertid gir Microsoft en løsning, som er nesten like enkelt som det du ville skrive i Unix/Linux:

    int disk_fd = åpen ( "/dev/hda1", O_RDWR);

Dette ville åpne harddisken partisjons /dev/hda1, å lese en kan kalle lese (), til å skrive en kan kalle write (). Enkel og grei, er det ikke? Under Windows NT/2000/XP, hvis du bruker WIN32 API /5/, funksjon Create () ikke bare tillate å opprette og åpne filer, men også partisjoner:

    HANDLE hPhysicalDrive = Create ("\\\\. \\ PhysicalDrive0",
                                       GENERIC_READ | GENERIC_WRITE,
                                       FILE_SHARE_READ | FILE_SHARE_WRITE,
                                       0, OPEN_EXISTING, 0, 0);

Lesing og skriving disken sektorer kan nå gjøres via Readfile () og Writefile ().

For et øyeblikk kan du tror at du kan bruke den samme Win32 funksjon under Windows 9x/ME. Men hvis du leser på i dokumentasjonen for Create (), vil du finne:

	Windows 95: Denne teknikken fungerer ikke for å åpne en logisk stasjon. I
	Windows 95 og oppgi en streng i dette skjemaet fører Create til retur
	en feil.

Under Windows 9x/ME Microsofts Win32 dokumentasjon anbefaler å ringe BIOS Int 13h via VWIN32, en av systemets VxDer (kernel drivere). Hvis du prøver å gjøre det, men du vil ikke lykkes. Problemrapport Q137176 i Microsoft Knowledge Base sier at – til tross for hva den offisielle Win32 dokumentasjonen sier – dette fungerer bare for disketter, ikke for harddisker. Som problemrapporten sier, for harddisker den eneste måten er å ringe BIOS Int 16h i 16bit kode. Å kalle 16bit kode fra et 32bit program, må du Microsofts “32bit til 16bit thunking” … Dette er ikke bare en annen API (med andre udokumenterte funksjoner eller dokumentert feil?), Thunking krever også Microsofts thunking kompilator, som fra en definisjon skript genererer assembler kode. Fra at en 16bit og en 32bit objekt fil må genereres ved hjelp av Microsofts assembler MASM. Disse vil bli koblet med noen dozend linjer med C-kode, som du må skrive, noe som resulterer i en 16bit og 32bit DLL (Dynamic Link Library). Forresten, trenger du ikke bare 32bit Visual C++ for dette, men du må også ha en gammel 16bit-versjonen av Microsofts C-kompilator … Har du det? Ved hjelp av en bunt av proprietære, ikke mye brukt verktøy, ikke ville være en god løsning for en Open Source programvare verktøy som LTOOLS!

Oppsummering: Det må være separate versjoner for DOS/Windows 9x/ME, Windows NT/2000/XP og Linux/Unix. For å skjule dette fra brukeren så langt som mulig, LTOOLS prøver å finne ut under hvilket operativsystem den kjører og automatisk ringer riktig kjørbar.

Tabell 1: Lavt nivå harddisk tilgang

Under DOS Under Windows 9x/ME Under Windows NT/2000/XP Under Linux/Unix
  • BIOS Int 13t
    (trenger BIOS Extensions for disker over 8GB)
  • DOS programmer:
    som DOS, men må bruke volum låse / låse opp for skrivetilgang
  • Win16 programmer:
    må ringe BIOS Int 13h via DPMI
  • Win32 programmer:
    32bit til 16bit thunking til en Win16 DLL
  • DOS programmer:
    ikke tillatt
  • Win16 programmer:
    ikke tillatt
  • Win32 programmer:
    Create (), Readfile (), Writefile ()
  • open (), lese (), skrive ()

Sikkerhetsbekymringer?

Ja, ha LTOOLS til en viss grad kan utgjøre sikkerhetsproblemer. Hver bruker, som kan kjøre dem, kan få tilgang til og endre filer på Linux filsystem, for eksempel endre fil tilgangsrettigheter eller fil eiere, bytte passord filer osv .. Men dette er mulig med en enkel disk editor, også. Kanskje er det bare en litt mer behagelig, når du bruker LTOOLS. Likevel er ubegrenset tilgang bare mulig, hvis du kjører under DOS eller Windows 9x/ME. Under Windows NT/2000/XP den LTOOLS brukeren må ha administratorrettigheter for å få tilgang til harddisken direkte. Under Unix/Linux i de fleste standardinstallasjoner også bare sys admin har tilgangsrettigheter for ‘rå’ diskstasjoner /dev/hda, /dev/hda1, etc ..

Er det noen alternativer?

De LTOOLS er ikke den eneste løsningen for å få tilgang til Linux filer fra DOS/Windows. Sannsynligvis Claus Tøndering sin Ext2tool /6/, et sett av kommandolinje verktøy, utviklet i 1996, var den første løsningen på dette problemet. Imidlertid er Ext2tool begrenset til lesetilgang og kjører ikke under Windows NT. Basert på Ext2tool, Peter Joot i 1997 skrev en Windows NT versjon, fortsatt begrenset til bare å lese /7/. Begge programmene er skrevet i C, kildekoder er tilgjengelige.

John Newbigin gir oss Explore2fs /8/, som kommer med en veldig fin GUI og kjører under Windows 9x og Windows NT. Med sin lese- og skrivetilgang gir det de samme funksjonene som LTOOLgui. BTW: John har gjort store arbeidet, fordi han klarte å gjennomføre Microsofts 32bit til 16bit thunking (se ovenfor), selv under Borland sin Delphi! Som alle Delphi programmer Explore2fs integrerer ‘sømløs’ i Windows, men porting til ikke-Windows-operativsystemer kan være vanskelig.

Historie og framtid

Den første versjonen av LTOOLS ble opprettet under det opprinnelige navnet ‘lread’ av Jason Hunter og David Lutz på Willamette University, Salem/Oregon (USA). Denne første versjonen kjørte under DOS, kunne vise Linux katalog oppføringer og kopiere filer fra Linux til DOS og var begrenset til små IDE harddisker og Linux på primære partisjoner.

Forfatteren tok over vedlikehold og videreutvikling i 1996. Siden da har de LTOOLS lært å håndtere større harddisker, tilgang SCSI disker, kjører under Windows 9x/ME og Windows NT/2000/XP, ekstra skrivetilgang og ble oversatt tilbake til UNIX, for å gjøre dem kjøre under Solaris og Linux selv. De fikk en nettleser basert og en Java-basert grafisk brukergrensesnitt etc. etc .. Mange Linux-brukere, de fleste av dem navngitt i kildekoden, hjalp i testing og debugging. Takk skal du ha.

I mellomtiden har LTOOLS nådd versjon v4.7/1/, kanskje enda mer, når denne artikkelen blir publisert. I tillegg til flere funksjoner, har mye bugs blitt fikset – og mest sannsynlig nye har blitt innført. Et vanlig problem har vært gjennom årene: Ingen gjorde forutse den raske hastigheten i harddisk-teknologi, hvor diskstørrelser har eksplodert, noe som permanent rammet operativsystemet grenser. Husker du DOS problemer med 512MB disker, Windows 3.x problemer med 2GB partisjoner, BIOS grense på 8 GB og de ulike problemer som Windows NT har på 2GB, 4GB og 8GB? Det er bare et øyeblikk siden! Og forresten, selv Linux har sitt problem: I kjerner før 2.3, kan ingen fil overskride 2 GB, som Linux som de fleste 32bit Unix-systemer bruker en signert 32bit offset peker i lese () eller write () (dette vil bli løst i kjernen 2. 4 ved å endre forskyvninger til 64-bits verdier, men opprettholde oppadgående forenlighet kan drive Linux inn i de samme problemene som vi diskutert for Windows ovenfor). Programvare standardisering for disktilgang alltid var mye tregere enn disken utviklere, så de oppfant proprietære løsninger for å overvinne operativsystemet grenser. Og alltid LTOOLS -og mange andre programmerere – måtte håndtere det … Så ikke bli sint, hvis LTOOLS ikke fungerer for deg på din splitter nye 64GB-stasjonen. Det er Open Source, så bare prøve å bidra til å feilsøke og videreutvikle dem! Og alltid LTOOLS -og mange andre programmerere – måtte håndtere det … Så ikke bli sint, hvis LTOOLS ikke fungerer for deg på din splitter nye 64GB-stasjonen. Det er Open Source, så bare prøve å bidra til å feilsøke og videreutvikle dem! Og alltid LTOOLS -og mange andre programmerere – måtte håndtere det … Så ikke bli sint, hvis LTOOLS ikke fungerer for deg på din splitter nye 64GB-stasjonen. Det er Open Source, så bare prøve å bidra til å feilsøke og videreutvikle dem!

Og ikke glem, hvis du bruker de LTOOLS: Gjør det på eget ansvar! Lesetilgang til Linux er ukritisk. Men hvis du bruker skrivetilgang for å slette filer eller endre filattributter på Linux disk, de LTOOLS – og du som bruker – kan gjøre en masse tull. Så alltid holde en backup!

Referanser

  1. http://www.it.fht-esslingen.de/~zimmerma/software/ltools.html: Hjemmesiden til LTOOLS
  2. Michael Tischer: PC-Intern 4. Data-Becker-Verlag
  3. http://www.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files.html Ralf Browns interrupt liste for x86-PCer
  4. http://metalab.unc.edu/pub/Linux/system/filesystems/ext2/Ext2fs-overview-0.1.ps.gz: Gadi Oxman oversikts om Extended to filsystem.
  5. Microsoft Windows Win32 API – Dokumentasjon, kommer med de fleste Windows C-kompilatorer eller på MSDN CDer
  6. http://metalab.unc.edu/pub/Linux/system/filesystems/ext2/ext2tool_1_1.zip: Claus Tøndering er Ext2tool
  7. http://metalab.unc.edu/pub/micro/pc-stuff/Linux/utils/dos/ext2nt.lsm: Peeter Joot er Ext2nt
  8. http://uranus.it.swin.edu.au/~jn/linux/explore2fs.htm: John Newbigin sin Explore2fs

Om forfatteren

“I det virkelige liv” Werner Zimmermann gjør undervise kontroll prosjektering, digitale systemer og datamaskinarkitektur ved FH Esslingen – University of Applied Sciences, Esslingen, Tyskland. Han har en hardware og software bakgrunn i bil- og industri embedded systemer. Hans ‘karriere’ som et Linux-system programvareutvikler startet i 1994, da han kjøpte en CD-ROM-stasjonen, som ikke ble støttet av Linux … Så han utviklet ‘aztcd.c’, en Linux-CD-ROM-driveren, som fortsatt er inkludert i alle standard Linux kjerner, selv om stasjonen er nå svært mye foreldet.