Google Drive heft limiet van vijf miljoen items weer op

Google Drive heft de limiet van vijf miljoen items weer op. Dat heeft het bedrijf laten weten. De zoekgigant had de limiet enkele maanden geleden ingesteld, maar had dat nergens tegen gebruikers gezegd en zette er ook niets over in supportdocumentatie.

De limiet trof 'een beperkt aantal personen', zegt Google. Daarbij ging het vermoedelijk wel om de grootste en meest betalende klanten. De limiet was volgens Google nodig om de stabiliteit van de webopslag te waarborgen en de prestaties te optimaliseren. Nu gaat Google daar andere manieren voor vinden, zonder een limiet te stellen op het aantal bestanden dat mogelijk is in een Drive-account.

Google zegt er nu bij dat als het wijzigingen doorvoert, het klanten en gebruikers van tevoren op de hoogte zal stellen. Dat gebeurde nu niet. Dat de limiet er was, kwam pas naar voren toen er meldingen kwamen. Pas daarna bevestigde het bedrijf dat er een limiet was.

De pop-up die verschijnt als gebruikers meer dan vijf miljoen bestanden hebben aangemaakt in Google Drive

Reacties (68)

[MotorLum]

Dat was dan een zeer korte beperking. Wat zou de reden zijn, alle ophef? Of toch nieuwe inzichten? ben benieuwd.

[Daniel Jackson]

Ik las iets over bestandsnamen gebruiken als opslag. Een bestand wordt met een speciale tool opgedeeld in talloze piepkleine bestandjes die leeg zijn, maar waarvan de data zich in de naam bevindt. Zo telt het dus nauwelijks mee voor de opslag, maar de data is er wel.

[Cergorach]

Heb je daar een linkje voor? In het vorige topic riepen verschillende mensen dit ook, ik kon er niets zinnigs over vinden en bij testen kreeg ik gewoon bestanden die ruimte innamen. Wellicht doe ik iets verkeerds of is dit iets ouds wat ondertussen gefixt is...

[crazyboy01]

Ik heb hier niets over gelezen, maar ik denk wel dat je iets fout doet als je bestanden toch ruimte innemen. Upload je misschien de originele bestanden? Mijn gok en zoals ik het lees is namelijk dat het compleet lege bestanden zijn (dus 0kb bestanden), die als bestandsnaam een deel van de data hebben (in welke vorm dan ook. Bv delen van code of bytes). Die kan een speciale tool vervolgens lokaal weer samen voegen tot één geheel waardoor het weer een uitvoerbaar geheel is. Die 5 miljoen bestanden van 0kb nemen 0kb in aan opslag (of heel iets meer), maar je kan in theorie wel opslaan voor miljoenen gb op die manier.

Dit is althans dus zoals ik het begrijp, en ook iets wat zonder limiet aan het aantal bestanden gewoon zou moeten werken.

[Terry A Davis]

Doet me een beetje denken aan de broncode van Jan Sloot, ook zo'n uitvinder die data in vrijwel niets wist op te slaan. Maar helaas vlak voor een belangrijke zakenovereenkomst is overleden.

De Broncode Van Jan Sloot en Roel Pieper Deel 1 tot en met Deel 3

En Roel Pieper is niet iemand die je makkelijk voor de gek houdt.

Wat je omschrijft is lijkt me bestandsallocatie inodes gebruiken als data opslag wat een truukje is. Wel leuk bedacht eigenlijk. Bij Microsoft NTFS worden hele kleine bestandjes kleiner dan een cluster in de MFT opgeslagen overigens. Dat is hetzelfde idee.

[PtrO]

Aan de wet van Shannon valt niet te tornen ;-) .
Informatie kan maar tot een bepaalde grens worden verkleind en zal daarna leiden tot verlies aan inhoud.

Bij Sloot was het ergens interessant omdat het algoritme uitging van een grote database waarin alle mogelijke informatie(beeldjes) waaruit een filmbeeld "kan" bestaan al was opgenomen; en iemand dan door één code cq formule; die combinatie kon samenvoegen tot een lange film.
Anders gezegd, voor elke (niet bestaande) flim waren de pixel-bouwstukjes als fragmenten - zoals bv ook gebruikt bij mpeg/jpeg codering - al aanwezig en kon dan met één codewoord worden omgezet tot een flim met desnoods ondertiteling.
Iets dat bv muziek "gebeurd". Wanneer je alle toonsoorten zou samplen in een database, kan je theoretisch daarna alle muziek maken die maar mogelijk is (in gedachten dan). Een variatie op dit thema is dat iemand met 26 letters of zo je wilt met één bit, elk verhaal; nu en in de toekomst zou kunnen (be)schrijven.
De entropie van informatiebehoud maakt dit echter onmogelijk omdat het aantal mogelijke combinaties van het codewoord minimaal net zo lang is als de totale inhoud die het zou moeten duiden.

Een tussengedachte - waarom Roel Pieper als commerciële visionair instapte - was om (alle) bestaande films alvast op één (goedkoop & transportabel) medium te zetten en een gebruiker dan met een toegangscode zijn film één of meer keer kon uitlezen. Prachtige gedachte dat je al je films en muziek in een doosje hebt van zeg 5x10*2cm en alleen maar een code hoeft te hebben om de daarin opgeslagen inhoud te zien.

[Reactie gewijzigd door PtrO op 25 juli 2024 12:24]

[RobIII]

Bij Sloot was het ergens interessant omdat het algoritme uitging van een grote database waarin alle mogelijke informatie(beeldjes) waaruit een filmbeeld "kan" bestaan al was opgenomen; en iemand dan door één code cq formule; die combinatie kon samenvoegen tot een lange film.

Heb je daar een bron van? Want de hele crux was nou net dat niemand wist hoe 't werkte. Dat 'ie uit z'n nek lulde is een ding dat zeker is, daar niet van, maar je geeft hier aan te weten hoe 't gewerkt zou hebben.

[PtrO]

Kheb o.a. destijds het boek "De Code" gelezen, Staat nog ergens deep-down-inside een kast. Daarin stond o.a. die hint stond en dat verder aangevuld met wat invulgedachten. Ik zal 's kijken of ik het ergens kan terugvinden om inhoudelijk wat relevants te citeren.

Wat ik mij er nog van kan herinneren dat elke alfa-techneut - had toen wat leuke discussies met deze en gene die niet bekend zijnde met o.a. Andrew S Tanenbaum's uiteenzettingen en de genoemde Shannon - er met open ogen en vol in zou stappen.
Er zijn meer dan genoeg, ook slimme mensen zoals destijds Roel Pieper, die te graag iets willen geloven. Voor een begeesterd mens is het moeilijk te bevatten dat tal van zaken, op grond van wetmatigheden, begrensd zijn.

De kern was dat elke film bestaat uit gepixelleerde (delen van)beeldjesfragmenten en als je die maar ver genoeg opdeelt -en uiteenrafelt er zg "vanzelf" een herhalende reductie op grond van herhalingen kan plaatsvinden. Voorbeeld: 1234=1+2+3+4=1+0=1. Dat men vanuit dat #hasgetal 1 never nooit, de oorspronkelijke 1234 kan afleiden, is intuïtief tegenstrijdig.
Voorbeeld dat ik ik illustratie even bedenk, Richard Gere speelde in "An Officer and a Gentleman" maar ook in "Pretty Woman". Dus het gezicht of wenbrauw van Richard in beide films, kan dan tot herhalende code worden gereduceerd. In het boek was en ging het - ik vertaal het even vrij naar nu - vooral over een doorgetrokken variant van JPEG/MPEG.

Update, was FF zoeken. het boek is van Eric Smit en heet "De Broncode". FF bladeren en quoten ter info. Sloot (TV technicus net kennis gemaakt met de IBM computer, we leven hier 1984) wilde een

... landelijke database met reparatie gegevens creëeren. Van ieder appraat zouden het typenummer, fabrikant en elke denkbare foutmelding met oplossing en de beschrijving van het mogelijk te vervangen onderdeel staan. Elke idioot met een schroevendraaier zou dan een televisie kunnen repareren. ...

Die centrale gedachte vergroeide naar het (feitelijk onmogelijke) idee nu 11 jaar later in 1995.(Sloot:)

Hij kon ook videobeelden coderen. Niets was moeilijker dan het verkleinen van bewegende beelden. De compressiewetenschappers hadden het nog niet verder gebracht dan een verkleiningsfactor - zonder kwaliteitsverlies - van twee. Sloot had iets bedacht, waardoor het beter kon, veel beter. Het was een absolute doorbraak, wist hij.

Wat later 1999 en verderop in het boek bij omzwervingen via KPN en Philips:

... voor zijn systeem werd een programma ontwikkeld waarvan de werking alsvolgt is. De tekst wordt ingelezen in de Data Key Decoder (DKD). In de Program Key (PK) zitten alle programma-algoritmes voor de berekeningen (coderen en decoderen) opgeslagen, als de berekening van de eerste pagina is uitgevoerd, wordt de waarde tijdelijk opgeslagenin de Character Key Decoder (CKD) Daarna volgt de codering van de tweede pagina enzovoort. Zodra alle pagina's zijn gecodeerd en opgeslagen in de DKD worden alle daar verzamelde paginacodes door de PK verwerkt tot een totale programmacode. Daar de opslag van het totale boek op deze manier slechts een paar codes bevat, zal de totale opslag slechts 1 kilobyte bevatten. Voor film wordt dezelfde techniek gebruikt, alleen praten we dan over pixels in plaats van karakters. ....

Kortom één film paste dan in kilobyte die je dan weer kon versleutelen om (eenmalig) uit te kunnen geven. Overal in het boek en ik zie het zo voor mij, gelardeerd met halve potjes gevulde augurken vermengd met zilveruitjes en visserslatijn. Ik kan mij zo voorstellen dat een beetje CEO er vol in zou stappen. Opvallend en nu onvoorstelbaar is dat (ook) deskundige mensen zich gepassioneerd lieten meevoeren met een wetmatige onmogelijkheid.

[Reactie gewijzigd door PtrO op 25 juli 2024 12:24]

[Nico Klus]

Ik moest door je uitleg denken aan fractal compressie, maar dat is niet lossless.

[PtrO]

Yep het SDCS (Sloot Digital Coding System) was als lossless neergezet en de verkleinde data - aldus het boek, dan - kon schokvrij in hoge kwaliteit op een Pentium 1 Windows95 computer afgespeeld worden.
Saillant is dat Sloot zelf nooit heeft gesproken over "(de)compressie" maar dus sprak over "(de)coderen en daarmee zelf - formeel dan - nooit de wet van Shannon heeft hoeven betreden.

Verder erg vermakelijk hoe mensen zich destijds lieten afleiden dat het knipperend ledje (van de harddisk) dat zou bewijzen dat de computer intensief aan het rekenen was.
Niet erg, we spreken in de tijd waar mensen erg snel geïmponeerd konden worden. In zekere zin niet veel anders dan nu en men (AI, dan) zonder twijfel over 30 jaar onze bespiegelingen van nu zullen gebruiken als input voor en van een vermakelijk terugblik van een simplistische periode.

[CrazyJoe]

Ik zou niet al te veel geloven van het verhaal van Jan Sloot, indien de "broncode" inderdaad gestolen zou zijn door een geïnteresseerde partij dan hadden we ondertussen allang iets teruggezien van deze unieke compressie techniek. Het feit dat we er nooit meer iets van teruggezien hebben geeft al genoeg aan dat er niets dan lucht achter zat.

En Roel Pieper zag waarschijnlijk dollars voor ogen tijdens de presentatie van meneer Sloot, wat je ook meteen genoeg moet zeggen over de drijfveren van Meneer Pieper.

Er is uitgebreid gekeken naar de claims van meneer Sloot door de mensen van Philips Research en dat waren echt geen domme mensen zonder kennis van zaken. Hun conclusie: er klopt niets van de beweringen van meneer Sloot.

Het feit dat er na de dood van Sloot geen spoor meer te vinden was van zijn "uitvinding" lijkt me eerder erop te wijzen dat zijn nazaten alle sporen van zijn "uitvinding" opgeruimd hebben om zo de mythe van Jan Sloot: Super Uitvinder, in stand te houden.

[veltnet]

Lege bestanden nemen toch ook ruimte in? Je moet op zijn minst de filename , creationdate, owner en ander metadata opslaan.

[Tweakenier]

Precies en bestandsnamen/metadata moet ook geïndexeerd worden voor de zoek/sorteerfuncties. Dus al met al kosten lege bestanden best nog wat data en rekenkracht voor Google.
Ik vermoed dat het limiet op het aantal bestanden was opgezet voor performance redenen voor de zoek/sorteerfuncties. Waarschijnlijk/hopelijk hebben ze die verbeterd.

[veltnet]

Als je je zoekindex bijwerkt op het moment dat je een file muteert dan zou performance geen probleem moeten zijn.

[Verwijderd]

Natuurlijk wel als je dit voor miljarden bestanden tegelijk wereldwijd moet doen, globaal CDNs en databases moet updaten, etc. I mean, het is vast te doen, maar dit is geen bedrijfje met slechts een paar terabyte aan data die even een SQL-indexje update.

[sebastienbo]

Lege bestanden nemen toch ook ruimte in? Je moet op zijn minst de filename , creationdate, owner en ander metadata opslaan.

Inderdaad, maar het zou dan slimmer geweesd zijn om die meta data ook mee door te laten wegen voor de bestandsgrootte, in de plaats van deze wankelige limiet te implementeren.

[Cergorach]

Ik maak een leeg bestand aan in Google Docs en die is per default al 1Kb.
Echter passen er 32767 characters in een bestandsnaam op Google Drive. In 1Kb passen 1024 characters. Je kan op die manier dus bijna 32x zoveel data kwijt in Google Drive...

Nu kan ik een lege txt file maken en die uploaden, maar de server geeft een error wanneer ik de naam wil veranderen naar iets met 32767 characters... Maar ik kan er bv. wel 1000 characters in kwijt...

De oplossing lijkt me om een limiet te gaan stellen op filename length, Windows, MacOS en Linux hebben geen van alle zo belachelijk veel characters in hun filename. Zet de limiet op 1024 en zet de minimum filesize op 1Kb (zelfs voor lege files).

[DLSS]

5.000.000 x 32kb is 160GB… ik geloof dat ik voor minder dan 10 euro per maand 2.000GB opslag heb bij google.

Cold storage (storage die je bijvoorbeeld max 1x per maand of 1x per jaar opvraagt) is bij de grotere aanbieders nog veel goedkoper.

Het lijkt me wel heel erg omslachtig om op deze manier geld te besparen. Ik ben echt benieuwd wat nu precies aan de hand is.

[Reactie gewijzigd door DLSS op 25 juli 2024 12:24]

[BadRespawn]

De oplossing lijkt me om een limiet te gaan stellen op filename length,

Google zou toch gewoon de daadwerkelijk ingenomen ruimte in rekening kunnen brengen en aan gebruikers kunnen tonen. Dus incl alles 'onder de motorkap', bvb FAT entry, bytelengte vd gebruikte sectoren (-minimaal 1 sector ook voor een leeg bestand) - of equivalenten daarvan.

[sebastienbo]

Waarom zetten ze die restrictie dan niet enkel op de gratis accounts in de plaats van hun betalende klanten.

[crazyboy01]

Omdat die ook geen unlimited opslaglimiet hebben, dus hetzelfde kunnen doen (al zou het een beetje raar zijn om dan nog te betalen voor opslag die je op deze manier niet nodig hebt, maar toch). Zo'n 100GB account kost geen drol, dan zou dat al een workaround zijn. Volgens mij is de echte unlimited storage alleen beschikbaar voor zakelijke accounts, geen idee of het daar ook voor geldt, maar lijkt me dat ze voor het gemak gewoon één lijn trekken.

[veltnet]

quote]Ik las iets over bestandsnamen gebruiken als opslag. Een bestand wordt met een speciale tool opgedeeld in talloze piepkleine bestandjes die leeg zijn, maar waarvan de data zich in de naam bevindt. Zo telt het dus nauwelijks mee voor de opslag, maar de data is er wel. [/quote]

Ja dan moet je de functie die de gebruikte bytes telt iets aanpassen. Dat moet Google toch wel kunnen?

[Reactie gewijzigd door veltnet op 25 juli 2024 12:24]

[sebastienbo]

Als dat waar is , dan is dat misbruik van gratis accounts.
Waarom dan betalende gebruikers ook straffen?

[RobinJ1995]

Ingenieus, vind het wel grappig Vroeger zo ooit ook nog een tooltje gebruikt, voor Google Drive uberhaupt bestond, om de (voor toen heel grote) gratis GMail storage te gebruiken als file storage. Was letterlijk een tool die je files als e-mail attachments opsloeg, en die je zo een network drive gaf in Windows waarmee je er bij kon als bij eender welke folder.

Zeer irritant voor de bedrijven, maar ik applaudisseer de creativiteit

[Scriptkid]

Meschien dan een dns naam kopen en al je data in txt records weg schrijven heb je unlimited zones en sub zones en kost niks.

[MvantLoo]

Stel dat een filenaam 1024 kan bevatten, dan "win" je met 5 miljoen bestanden slechts 5 GB aan opslag.

Dit lijkt me geen realistische aanpak om "gratis ruimte" te werven... Zeker niet gezien het werk wat je er aan hebt.

Denk ook aan de NTFS overhead op je eigen systeem. 5 miljoen bestanden aanmaken kost behoorlijk wat tijd, zelfs op snelle storage en met dikke CPU's... En daarna nog alle overhead van het synchroniseren naar Google....

Ik kan het me niet voorstellen dat iemand deze methode serieus gebruikt, behalve voor educatieve doeleinden....

[Marzman]

Allebei. Er was een probleem, iemand had een oplossing, daar kwam ophef over, nieuwe inzichten. Zoiets waarschijnlijk

[grasmanek94]

Dus nu wel maar de brakke code fixen? Ik heb toch nooit goede ervaringen met gdrive gehad dus helemaal links laten liggen. Vaak interruptie bij uploads, browsen van bestanden of vinden traag / niet te doen bij grote folders / veel items, en zelfs schoonmaken / trash verwijderen vaak http 500 errors, dus bij een te vol account niet eens op kunnen schonen. Ook van toepassing op hun client, die ook nog meer euvels heeft.

[Reactie gewijzigd door grasmanek94 op 25 juli 2024 12:24]

[NEO256]

Heb persoonlijke enorm goede ervaring met Dropbox voor syncen op telefoon en desktop.

Microsoft OneDrive gebeuren vondt ik altijd maar beetje "meh", vaak meldingen die de sync tegenhouden, onduidelijke communicatie van wat er nu aan de handt is en hoe je het op moet lossen.

Iemand anders die ervaringen wil delen over een van de 3?
En wat is jullie ervaring met Google Drive voor syncen op telefoon / desktop?

[djwice]

AWS S3? Niet goedkoop $0.023 per GB per maand plus kosten voor PUT/POST $0.005 per duizend en GET $0.0004 per duizend, maar wel altijd bij je bestanden kunnen, geen limieten (Peta bytes if you like).

Je krijgt er zelfs torrent protocol support bij.

[Scriptkid]

Dat kun je niet vergelijken met een google of one drive dan moet je ook vergelijken tegen azure blob storage

[djwice]

En met Alibaba Cloud OSS deze is volledig compatibel met de S3 API, dus wat voor AWS S3 werkt, werkt ook voor Alibaba Cloud OSS.

Maar waarom kun je S3 niet vergelijken?

Je kunt bijvoorbeeld gewoon een POSIX mount maken van 800Mbit/s met AWS S3 als je wil (als jouw internet bandbreedte dat toe staat) zonder extra kosten.


P.S.
Voor Azure zijn ook S3 API layers, zoals Min.io, vandaar dat ik AWS S3 refereerde, die API is de markt standaard. Als je tools gebruikt die werken met de S3 API, kun je ze ook koppelen aan (nagenoeg) alle andere blob storage providers.
Dit zorgt er mede voor dat blob storage overal ongeveer gelijk geprijst is. Immers 'switchen' naar de concurrent kost slechts een one time down/upload. Met een gemiddelde snelheid van ongeveer 93TB per dag bij files van 1kb - als de andere cloud provider dat ondersteunt.

[Reactie gewijzigd door djwice op 25 juli 2024 12:24]

[Verwijderd]

Dropbox is wel een beetje de koning van de sync oplossingen... Dat zeg ik vanuit mijn ervaringen 10 jaar geleden. Vooral bij moeilijke internetverbindingen (zoals in Azie) was er geen betere.

Tegenwoordig is het volgens mij allemaal wel redelijk op orde. Dropbox, Onedrive en Google drive zijn allemaal prima. Ik werk zelf de gehele dag met de laatste twee en kan mij de laatste keer dat ik problemen had niet eens herinneren. Ook de mobiele apps zijn prima.

Dat zeg ik wel vanuit een Europees perspectief... Geen idee hoe het in andere continenten is tegenwoordig.

[SCS2]

Dat komt omdat Dropbox op block niveau werkt, niet op file niveau.
Delen van een file die gelijk zijn, hoeven niet verstuurd te worden.

Bij 'al' die andere is het wijzigen van 1 bit al genoeg om een hele file van 100gb weer opnieuw te sturen.
Bij Stack was alleen het wijzigen van de datum al genoeg.

Ik heb mijn gevoelige sync-data in een veracrypt volume staan.
Daarom vind ik block-syncronisatie zo veel beter, ook wel delta-sync genoemd.
Tot mijn grote vreugde doet pCloud dat ook !!!
Maak daar nu al 5-6 maanden daar gebruik van, prima, volwassen software.

NB. pCloud maakt ook een cache-file aan, ik denk dat dat OOK op blockniveau werkt.
Daardoor werkt bijv. hun directory opvragen of het inzien van mijn online veracrypt-volumes heel vlot over mijn 50/10Mbit adsl lijntje.

[Yggdrasil]

Ik werk zakelijk met Box.com en die bevalt eigenlijk ook goed.

[moonlander]

Wat jij beschrijft heb ik nog nooit gehad en ben gebruiker van het eerste uur. Zou eerder zeggen dat het aan jou kant ligt dan.

[grasmanek94]

Ik weet jou gebruikssituatie niet, maar in mijn situatie beheerde ik het voor een bedrijf van 50 man, betaalde diensten van Google, en voor iedereen "onbeperkte" opslag.
Genoeg mensen die om hulp vroegen want het stopte vaak met syncen en was niet eenvoudig op te lossen. Ons backup account had oude backups die weg mochten, was niet te doen (wel honderden duizenden files). Ja er zijn betere backup solutions, dat weet ik. Het was wat 't was, neemt niet weg dat G-Drive gewoon hoorde te werken, en toch niet werkte. Misschien hebben ze het ondertussen beter gemaakt, maar gezien je zegt 'eerste uur' zou ik verwachten dat je ver voor het gebruik van Google Drive in het bedrijf al ermee aan de slag ging

[Verwijderd]

No offense maar Google drive is daar ook helemaal niet geschikt voor. Ik weet wel dat er vanalles door marketing geroepen wordt (ongeacht de leverancier, Microsoft doet dat ook) maar het is geen backup tool.

Iedere sync oplossing heeft last van deze problemen. Als je een backup tool zoekt, dan zijn er betere oplossing te vinden. Als je een sync oplossing zoekt voor je standaard bestanden, dan is Microsoft Onedrive, Dropbox of Google Drive prima.

[ZeroMinded]

Dat zou best kunnen, er is een dagelijks upload limiet van 750Gb.

[RobinJ1995]

Omdat jij er niet tegenaan loopt betekent niet dat het niet wel degelijk om reële problemen gaat. "Het ligt aan jou" bij software is onzin, tenzij je letterlijk op een knop klikt met beschrijving "loop vast" of "toon foutmelding" zijn deze scenarios gewoon bugs, maakt niet uit hoe ze voorkomen.

[moonlander]

Anders zou het internet er vol van staan en google drive geen succes zijn

[RobinJ1995]

Om een echt probleem te zijn hoeft het niet bij elke gebruiker en use case voor te komen... Zo werken dingen niet.

[moonlander]

Als het echt een issue was geweest voor vele mensen dan hadden we het er hier dagelijks over op tweakers.. Hij doet nu net of het alleen maar problemen waren..

[RobinJ1995]

Man, daar gaat het helemaal niet om... welk "punt" probeer je nou uberhaupt te verdedigen?

Ik zeg niet dat het een ramp is, ik zeg niet dat het bij iedereen voorkomt, en ik zeg zelfs niet dat het bij "vele mensen" voorkomt. Maar jouw argument dat omdat het bij jou nog nooit is voorgekomen het vast wel aan de kant van de gebruiker zal liggen is klinkklare onzin.
Bugs gebeuren. Foutmeldingen bij het leegmaken van de Trash heb ik zelf ook regelmatig voor. Maar discussiëren dat een probleem dat iemand overkomt niet echt is of zelfs aan de gebruiker ligt omdat jij het nog nooit bent tegengekomen en niet hele forums er mee volgespamd staan, ik denk dat je zelf ook wel ziet hoe... "onzinnig" die redenering is, toch?

[veltnet]

Wat jij beschrijft heb ik nog nooit gehad en ben gebruiker van het eerste uur. Zou eerder zeggen dat het aan jou kant ligt dan.

Dat is een gevaarlijk opmerking. Het feit dat jij ergens geen last van hebt zegt niks over andere gebruikers. Misschien heb jij een beperkte usecase of misschien heb je gewoon mazzel.

[crazyboy01]

Daar heb ik allemaal nooit problemen mee. Het enige dat ik wel heb ondervonden is dat er heel veel mis gaat als je incognito de webinterface wil gebruiken. Downloaden gaat dan bv niet eens (op verschillende besturingssytemen). Mogelijk inmiddels gefixt, maar is jaren zo geweest.

[CH4OS]

Ik heb deze issues dan weer nooit gemerkt, in het verleden niet, maar tegenwoordig al helemaal niet meer. Grote files up- en downloaden gaat gewoon prima. In het begin was dat nog weleens hopeloos, maar tegenwoordig gaat dat echt gewoon goed.

[John Doos]

Fijn, was al even bang dat dit nog een staartje zou krijgen.

Maar drive voor professionele opslag?
Sijpelt dit ook door naar Workspace ofzo dan?

[lenwar]

Dit voelt echt heel raar.
Ze hadden naar eigen zeggen dat dit was voor stabiliteit en prestaties. Ze geven zelf al aan dat het maar zeer weinig gebruikers hier daadwerkelijk tegen aan liepen. Ofwel. Ze hadden een oplossing bedacht via een mechanisme wat amper getriggerd wordt.

Het voelt toch echt alsof er wat anders achter zat dan wat ze aangeven.

[Verwijderd]

Ik denk eerder dat ze simpelweg het gezeur niet willen hebben. De problemen die hieruit voorkomen zijn toch op de computer van de eindgebruiker, niet hun back-end... Of als het maar zeer weinig gebruikers zijn, laat ze maar... het is de negatieve publiciteit niet waard.

[veltnet]

Het was gewoon een slechte en gebruikers onvriendelijke oplossing, en daar zijn ze zelf ook achter gekomen. Nu zijn er weer een paar managers terug gefloten.

[Reactie gewijzigd door veltnet op 25 juli 2024 12:24]

[lenwar]

En dat had de marketingmolen van een advertentieverkoper niet zelf kunnen bedenken?
Mogelijk heb je gelijk hoor, maar dit voelt toch alsof er iets anders was. (( zonder alu-hoedje ))

[veltnet]

Ja, dat had prima gekunt, maar in grote bedrijven werken mensen vaak lang elkaar heen.

[sebastienbo]

Ik botste nog niet tegen die limiet, maar het vooral schrik hier ze dit aangepakt hadden. Dit kon de voorbode zijn van andere changes die op dezelfde manier geïmplementeerd zouden worden
..

Stel je voor dat dit een test was voor te zien of gebruikers klagen of gewoon accepteren wat in hun strot geduwd word...

Als bedrijf werd ik er toch onrustig van.
Gelukkig dat de kar draait.

[FalconerHG]

Wist niet dat Musk Google had gekocht?

[Cergorach]

Before Musk there was Google...

Google is altijd behoorlijk schizofreen geweest met features en producten.

[MrHarry]

google wilde even gratis aandacht en in het nieuws komen met hun product?

[mrmrmr]

SSD's hebben soms ook zo'n beperking. Ik kon op een oudere SSD niet meer bestanden kwijt, ook al was de drive nog lang niet gevuld.

[crazyboy01]

De limiet van een SSD heb ik zelf nog nooit bereikt (en maar goed ook, want bv een Windows installatie wil nog wel eens wat bestanden gegenereerd hebben na een aantal jaar).

Maar, in principe is een limiet er altijd. Hoe hoog dat is, is afhankelijk van de manier van formatteren maar dat varieert meestal van enkele honderden miljoenen tot meerdere miljarden bestanden, dus dat zal niet het limiet zijn dat je hebt bereikt gok ik. Het limiet van 5 miljoen is veel eenvoudiger te bereiken met bv grote projecten.

[mrmrmr]

De grens was bereikt bij enkele miljoenen bestanden. Dus nog lager dan de limiet van Google.

[crazyboy01]

Interessant, ben wel heel erg benieuwd of er dan meer mensen op Tweakers zo'n limiet hebben bereikt en waar die dan lag. Zit er verschil in het limiet, zal dit op alle schijven zo zijn of enkel bij bepaalde merken of types etcetera? Een snelle Google opdracht brengt me niet heel ver, die geeft vooral info over de maximale grootte van bestanden etc. Zal zelf binnenkort ook eens een test doen...

[sebastienbo]

Devs die met libraries werken komen daar zonder probleem aan.
De bestanden kunnen ook niet in één zip file gestoken worden, anders vind de compiler ze niet terug... Of kan je geen search doen op content van de files

Githib syncs kunnen ook heel veel kleine files downloaden zonder je het door hebt

[Reactie gewijzigd door sebastienbo op 25 juli 2024 12:24]

[veltnet]

Dat hangt van het gebruikte filesysteem type (Fat/Ntfs/Ext2/3/4/etc) en de fysieke media (usb,ssd,cdrom,hdd)

[mrmrmr]

Het ging bij mij om een 128 GB en 250 GB drive met een heel groot aantal kleine bestandjes van minder dan 1 of enkele kilobytes. De block size is meestal 4kB. Je hebt zo dus grote aantallen gedeeltelijk lege blocks. Vermoedelijk was het aantal beschikbare blocks op.

Die kleine bestandjes stonden op de SSD omdat het zo snel ongeindexeerd doorzoekbaar is. Het bestandssysteem was FAT32 of NTFS. De bestanden stonden in een structuur, niet in 1 directory.

Oude CD-R CD's hebben ook beperkingen, bijvoorbeeld de diepte van een directory structuur is gelimiteerd.

@likewise @veltnet @sebastienbo

[Reactie gewijzigd door mrmrmr op 25 juli 2024 12:24]

[likewise]

SSD's kunnen geen beperkingen hebben in het aantal bestanden. Een SSD levert hoogstens een aantal blokken met data.

Het maximale aantal bestanden wordt bepaald door het bestandsysteem van het besturingssysteem, of de configuratie daarvan.

Er is vaak wel een relatie tussen de partitiegrootte en het max. aantal bestanden, maar dit verschilt per bestandsysteem.

[Dennisb1]

Ofwel, 1 Mei: Over 30 dagen gaan wij de beperkingen inschakelen van maximaal 5 miljoen bestanden bladieblabla want blablabla

[rikkert_1990]

Dan mogen ze eerst beginnen met het niet verliezen van data op de drive. Ik ben 3tb aan data kwijt door ze.. en de klantenservice is ver te zoeken.

[Willem_54]

Als je het aantal bestanden relatief makkelijk wilt beperken, maak dan eerst een ZIP-file of ander soort archiefbestand van mappeninclusief submappen voordat je deze op Google-Drive zet. Eventueel eerst ook nog van een wachtwoord voorzien voor extra veiligheid.