Gmail-box in Linux te mounten dankzij nieuwe software

De 1GB opslagruimte van Googles mailsysteem Gmail kan ook handig zijn om online bestanden op te slaan. Richard Jones dacht hetzelfde en heeft in twee dagen het Gmail-bestandssysteem ontwikkeld. GmailFS is een mountable Linux-bestandssysteem dat is geschreven in Python en gebruik maakt van FUSE voor het aanbieden van het bestandssysteem aan de kernel en libgmail om te communiceren met de Gmail-server. GmailFS ondersteunt de meeste bestandsoperaties, waaronder read, write, open, close, stat, symlink, link, unlink, truncate en rename, zodat vrijwel alle command line programma's gebruikt kunnen worden binnen het bestandssysteem. Dit is de eerste versie van GmailFS en tevens de eerste programmeerpoging van Jones in Python, dus de code bevat waarschijnlijk nog wel een paar foutjes. Op Jones' website wordt verder uitgelegd hoe het bestandssysteem geïnstalleerd en gebruikt kan worden en met welke bijzonderheden rekeninggehouden moet worden.

GmailFS aan het werk (klik voor een grotere versie)

Reacties (88)

[Verwijderd]

Vraag me af of google dit leuk vind. Krijg je straks allemaal isotjes die door google gehost zijn....

Ben benieuwd naar de reactie van google.

[solatis]

http://gmail.google.com/gmail/help/terms_of_use.html

"You also agree that you will not use any robot, spider, other automated device, or manual process to monitor or copy any content from the Service"

Als het echt zo ver komt, kunnen ze dus gewoon accounts gaan afsluiten...

[Verwijderd]

Het lijkt me dat hier wordt bedoeld dat je geen content van de gmail server mag afhalen (copy _from_). Er naar toesturen lijkt me geen probleem...

Een groter probleem (voor het wegzetten van minder legale iso's e.d. lijkt me deze regel: You shall not, shall not agree to, and shall not authorize or encourage any third party to: (i) use the Service to upload, transmit or otherwise distribute any content that is unlawful, defamatory, harassing, abusive, fraudulent, obscene, contains viruses, or is otherwise objectionable as reasonably determined by Google

Alhoewel je deze zin ook kan lezen dat het WEL is toegestaan om LEGALE data te UPLOADEN (dus de service als online opslag medium gebruiken.

Verder lijkt me dat als Google 1 GB aa ruimte beschikbaar gaat stellen ze niet moeten gaan janken dat deze ook daadwerkelijk gebruikt gaat worden.

edit:

@ Japs en solatis: Wie zijn probleem is dat dan? Toch zeker WEL die van Google. Als blijkt dat ze te weinig ruimte hebben gereserveerd, kunnen ze 2 dingen doen ja: OF de hardware uitbreiden, OF de faciliteiten terugschroeven. Vuistregel of niet, als je 1 GB aanbied moet je dat ook kunnen waarmaken te leveren.

[Japs]

@rmb1905

Verder lijkt me dat als Google 1 GB aa ruimte beschikbaar gaat stellen ze niet moeten gaan janken dat deze ook daadwerkelijk gebruikt gaat worden.

Hangt ervan af. Ik denk niet dat ze alle opslagruimte werkelijk hebben, dus stel als ze X gebruikers hebben dan zullen ze waarschijnlijk niet X * 1GB opslagruimte hebben. Een heleboel gebruikers zullen nooit die 1GB vol hebben, dus dat is in de praktijk ook niet nodig.
Ze zullen (net zoals alle webmail "providers" denk ik) een goed onderbouwde schatting gebruiken, die uitwijsd dat bijvoorbeeld 60% van het totaal ruim voldoende is om alle gebruikers voldoende ruimte te geven (de gebruikers die 1GB volgooien worden gecompenseerd door gebruikers die maar 100MB eropzetten).
Die schatting kan wel eens gebaseerd zijn op het feit dat de dienst is ontworpen voor mail-gebruik, dus misschien klopt de schatting niet meer als veel (?) mensen de 1GB gaan gebruiken als on-line data opslag. Dat zou dus extra harddisks betekenen, en dat kost geld.

[solatis]

Verder lijkt me dat als Google 1 GB aa ruimte beschikbaar gaat stellen ze niet moeten gaan janken dat deze ook daadwerkelijk gebruikt gaat worden.

Ooit van zoiets als business plan gehoord ? Het is gewoon niet winstgevend te maken als iedereen al zijn ruimte gebruikt, en daar hebben ze vanaf begin af aan rekening mee gehouden. Je berekent wat een gemiddelde gebruiker over 3 jaar aan ruimte in gebruik heeft, en doet daar nog een grote schep bovenop en je hebt GMail. Als die schep, die dus volgens berekeningen niet gebruikt wordt, dan toch gebruikt wordt, en dat dit gebruik in strijd is met de gebruiksovereenkomst, vind ik het niet meer dan terecht dat ze dit soort mensen wegtrappen.

[Verwijderd]

Wat daar staat kan zelfs opgevat worden als "je mag deze service niet gebruiken". Namelijk: dat handmatige proces... dat is iets wat je doet als je je gmailbox bekijkt.

[pietje63]

to monitor or copy any content from the Service

Dat mag dus niet, het verstruren en ontvangen van e-mail is niet gelijk aan monitoren of copiëren van gegevens (tenzij je grote hoeveelheden mail naar je zelf mailt want dan is het een soort van copiëren)

[Verwijderd]

Het gaat nog verder: er staat dat gebruik van gmail (automated device) voldoende reden is om de account te beeindigen. Dit is een zwarte-lijst clausule en maakt de positie van Google heel zwak. Ik neem aan dat Google daarom bij verschil van mening zal proberen mensen af te bluffen/blaffen.

[TD-er]

Ik vraag me af of het wel zo handig is voor online-hosting. Je kunt het prima gebruiken voor je eigen files, maar ik zou het niet gebruiken om files voor anderen te hosten.
Voor zover als ik begrepen heb zullen die files toch echt alleen via Pop3, imap oid te benaderen zijn en dan moet je dus je password gebruiken om erbij te komen.

[TukkerTweaker]

Daar zal GmailFS wel voor zorgen dus. Een paar symlinkjes in je apache htdocs en je hebt een snelle webserver tot je beschikking voor noppes!

[Mayco]

euhm, nee, die symlinks worden door je eigen webserver geresolvt en gelezen. Je zal dus zeker geen snelle webserver hebben aangezien de bestanden zo gaan:
google-server > GmailFS > apache > client
je apache zelf moet dus de files eerst downloaden van google en dan uploaden naar de client.

[Bleh!]

Dat zal wel meevallen want dan gaat het nog steeds ook via je eigen server.

[Olaf van der Spek]

Voor zover als ik begrepen heb zullen die files toch echt alleen via Pop3, imap

GMail support toch geen IMAP of POP3?
Alleen HTTP dacht ik.

[Verwijderd]

Volgens mij klopt dat ook, dus is FUSE een programmatje welke de protocollen integreert met alle functies van http. Dit is in zekere zin ook al mogelijk met KDE Konqueror, hiermee kan je als URL verschillende protocollen aansturen. Bijvoorbeel kan je als adres opgeven in de url : MAIL://[e-mail] en dan krijg je gewoon je mailbox te zien, of het nu imap of pop is maakt niet uit, behalve dan dat imap meer mogelijkheden biedt. Na fish zal fuse dan de nieuwste protocol zijn dat we met een *nix bakje naadloos integreren in ons bestandsysteem, erg kool!

one step closer to world domination...

[Verwijderd]

Gewone doorsnee huis tuin en keuken email comprimeerd buitengewoon goed, met 1 gigabyte ongecomprimeerde mail heb je gecomprimeerd misschien 100 mb nodig...

Maar het word anders als je divx films of iets dergelijks op je 1 gigabyte account gooit...

Dat je dus 1 gigabyte mailserver hebt, zegt niks, het gaat erom hoeveeel er overblijft na sterke compressie...

[kamerplant]

Platte text is goed te comprimeren, een reeds gecomprimeerde DivX (Divx mpeg4 compressie ) kan amper kleiner worden. Je zit in dit geval eerder met een boel overhead.

[marsattacks]

Ik vind het opzienbarender dat je een filesysteem in python kunt schrijven. Is dat zo'n krachtige taal?

Ik dacht nl. dat je dit voor linux alleen in C kon maken.

[[BoSS]]

Hij maakt ook gebruik van externe libraries (zoals vermeld in de posting). Ik denk zelf ook niet dat het in alléén Python mogelijk is.

[mOrPhie]

Als er bindings voor de taal zijn kun je er software mee schrijven.

Iemand heeft ooit GTK-bindings voor PHP gemaakt. Nu kun je dus een GTK-programma voor linux maken, met PHP.

[MachoM]

Hij heeft dan ook FUSE voor het file-systeem gebruikt, wat in z'n geheel in C is geschreven.

http://sourceforge.net/projects/avf

[TD-er]

Met Python kun je prima programma's maken die kunnen lezen en schrijven in een file en tevens netwerk-verkeer kan doen.
Een voorbeeld van een bekend programma, wat in Python is geschreven is Spamassassin.

[leadpumper]

Euh, SpamAssassin is volgens mij geschreven in Perl...
* 786562 leadpumper

[Verwijderd]

Misschien bedoelde TD-er wel SpamBayes

Maar hoe dan ook: Python is een erg lekkere taal waarin je enorm snel kunt werken

Proxy bouwen kan in minder dan een uur als je wilt

[smokalot]

ik neem aan dat dit dus over http gaat? mooi idee, maar ik moet zeggen dat ik mn twijfels heb om zo'n module in mn kernel te stoppen

ben benieuwd of het een beetje stabiel is. snelheid zal het probleem niet worden denk ik, 100kb per seconde moet toch haalbaar zijn.

[infirit]

Dit hoef je niet in je kernel te stoppen. Het maakt gebruik van fuse, lees userland filesystem

[Bleh!]

Kijk dat is nou een origineel idee. Ik ben benieuwd of dat nog wat performance levert.. Gmail is wel snel maar als filesystem niet echt lijkt mij.

[Sfynx]

Het zal wat overhead hebben als filesystem, maar of dat te merken is...

[Verwijderd]

Ik weet niet of hij persé doelt op de overhead. Het is natuurlijk wel een opslagplaats op het internet dus je bent afhankelijk van de snelheid van je internet verbinding (er vanuitgaande dat de toegang vanaf je ISP naar GMAIL optimaal is).
Bovendien is Gmail een webbased mailaccount, het lijkt me wel enige overhead hebben om bestanden up- en down te loaden, aangezien de nodige vertaalslagen gemaakt moeten worden.

[Verwijderd]

Heb zitten zoeken op verschillende GMAIL-sites, maar kan nergen wat vinden over data-transfer-limieten van deze mailboxen..
Lijkt mij dat Google dat toch wel ergens gaat monitoren/bijhouden/limiteren.
Iemand meer info?

Edit:Typo-tje

[Verwijderd]

is dat mogelijk om te booten van uit gemail???

is dat niet een beetje omslagtig, als remote OS oke maar gewoon als thuis gebruiker lijkt het me toch niet echt handig.

dan zou ik eerder denken aan een externe HD of of multi boot CD/DVD..

wat jullie

[Parlor_Inventor]

Als jij een BIOS hack schrijft die zelf op Gmail kan inloggen en zo kan booten... Anders heb je nog steeds een OS nodig om netwerkconnectie op te zetten, verbinding met Gmail te maken, enzovoorts.

[Verwijderd]

je bios ondersteund ook geen ext3, ntfs of welk filesystem je ook gebruikt. het enige wat je bios doet is een programmaatje op de boot sector opstarten die daar *wel* verstand van heb.
op linux systemen heb je meestal een bootloader zoals grub of lilo, die vervolgens de initrd laadt (of de boot sector van een andere partitie, als je bv windows wilt booten).

zoals infirit hieronder al aangeeft zit de gmailfs driver niet low-level genoeg om van te booten, en booten van gmail zal dus volgens mij niet werken.

en over die thin clients: de juiste term hiervoor ie niet thin client, maar diskless client, oftewel een client zonder eigen harddisc, die vanaf het netwerk boot.
alleen denk ik dat zelfs als je een kernel-implementatie hiervan hebt, dat gmail gewoon te traag is, en je veel te lang zit te wachten voordat ie klaar is met laden.

[wacko]

Ja natuurlijk is dat onhandig en omslachtig; het gaat om het idee (en het was natuurlijk een grapje).

@Pietje Puk: hij bedoelde dan wat anders onder de term 'thin client' ja

Ik heb het zojuist geprobeerd. Het is extreem langzaam, soms duurt het tientallen seconden voordat een bestand van een paar KB is opgeslagen, maar als het eenmaal aan het transferen is gaat het vrij aardig. Ik heb een ping van ongeveer 110 ms naar gmail.google.com, maar tijdens gewoon gebruik van gmail is de snelheid ook nogal variabel.

[infirit]

Dit zal moeilijk gaan omdat het geen kernel space implementatie is! Het is een userland filesystem dat op het moment van de het booten nog niet beschikbaar is. Het zou misschien kunnen met initrd? * 786562 infirit

[Verwijderd]

Lijkt met erg moeilijk (ik ben ook niet echt een expert ofzo op dat gebied, trouwens), maar ik denk niet dat het een enorm probleem gaat worden om bijvoorbeeld alleen maar je (Linux) core op een CD of USB stick te zetten en vandaaruit de rest te mounten. /var/ en /home/ bijvoorbeeld.

[Verwijderd]

En google gaat dit zomaar toelaten.... dream on!

[Joop]

Google zal natuurlijk wel alles er aan doen om dit te voorkomen. (Ook als warez gebruik.) En dat zal ze waarschijnlijk ook wel lukken op de lange termijn.
Maar op de achtergrond gebruikt GmailFS gewoon e-mails met attachments. (Opzich logisch.) Het zou voor Google nog best moeilijk kunnen zijn om dat te blokkeren. Hoe scheiden ze de legitieme mail met attachments van de GmailFS mail met attachments? Tricky!!

[Verwijderd]

Simpel.
Ze maken een robot om alle attachments van de losse files te scheiden.
Zal toch niet zo moeilijk zijn?

Zal je net zien.. versie 2 van de software..
ie gooit een shell om alle files heen zodat ze net lijken op een message met attachment...

[Joop]

Dat lijkt mij dus wel moeilijk. Er staan 2 mails in je inbox, allebei met een normaal subject en allebei met een attachment in een niet standaard formaat. (Dus geen .zip ofzo maar zonder extensie of met een onbekende extensie.) De ene mail is onderdeel van GMailFS, de andere is een zelf gestuurde mail met als attachment de data file van één of andere applicatie.

Hoe moet een script/robot/whatever nou herkennen welke van de twee van GMailFS is? Er is geen zichtbaar verschil!

[Sfynx]

@Joop: Die attachments van GmailFS zullen vast wel herkenbare data bevatten specifiek voor GmailFS.

[Verwijderd]

Dit gaat over secure http, dus wat dat betreft is het wel redelijk veilig lijkt me.

Wat ik me overigens wel afvraag is of dit nou wel zo'n succes gaat worden. Iedereen heeft tegenwoordig wel een USB stick, CD brander, DVD brander of ZIP-drive of iets dergelijks; dat lijkt me toch wat simpeler en sneller.

[EJP]

Een usb stick, cd brander dvdbrander en zip kosten geld. Een usbstick van 1 gig kost veel geld, dus dan zou dit nuttig zijn.

[kamerplant]

Plus dat je USB stick niet overal ter wereld berijkbaar worden gaat.

Of dit een succes wordt? Tuurlijk niet.
Ten eerste gebruikt een zeer klein percentage Linux, daarbij vind Google er absoluut wel iets tegen als dit populair wordt, plus dat het natuurlijk onbetrouwbaar is. 1GB aan documenten kun je zomaar kwijt raken aangezien je tegen de policy van google werkt.

[Verwijderd]

Misschien is de communicatie wel veilig maar Google kan dan wel bij je bestanden. Enige vorm van encryptie is wel handig voor vele toepassingen hiervan.

[BarôZZa]

Als je illegale bestanden host op Gmail, dan kan niemand daar trouwens toch iets tegen doen? De vrienden bij Google mogen tenslotte niet in je mail kijken. De enige manier om gepakt te worden zou dan zijn door het bestand naar de verkeerde te sturen.
Op zich ideaal voor veel mensen, aangezien behoorlijke gratis webhosting tegenwoordig nergens meer te krijgen is(waar je dus bestanden op kan hosten).

@ _Pussycat_: Dat is volgens mij geautomatiseerd en alleen voor de reclamedoeleinden.

[_Pussycat_]

In het contract wat je met gMail afsluit staat dus juist dat ze wel je mails mogen lezen (wat ze doen om je reclame te sturen).

[Verwijderd]

Bijna goed, er staat dat hun bots je mails mogen gebruiken voor die advertenties bovenaan het scherm

[Verwijderd]

Je kan ze toch autmatisch laten encrypten voor ze naar Google gaan. Geen probleem hoor.