Bericht door: KeesZ op 07 januari 2016, 17:53:15
Grote bestanden ontvangen zou zeer eenvoudig via file request gaan en bestanden verzenden zou zeer eenvoudig via een sharelink gaan. Echter blijkt na de aanschaf van dit apparaat hier niets van waar te zijn: file request staat alleen bestanden toe met een grootte tot 2GB, en bestanden groter dan 4GB kunnen via een sharelink NIET worden ge-unzipt op een Mac. De support van Synology is echt dramatisch, de ene medewerker beweert hele andere en tegenstrijdige dingen dan de andere, maar feit is dat het beloofde niet kan worden waargemaakt.
Heeft iemand advies? Ik heb al gezocht bij codecanyon punt net voor scripts maar vele werken niet en andere hebben gelijkwaardige limieten. Zo moeilijk kan dit toch niet zijn????
Bericht door: Stephan296 op 07 januari 2016, 18:09:52
Krijg je dan een foutmelding ofzo? (Ik ben een Windows gebruiker)
Die limiet van 2gb zegt mij eerlijk gezegd niets.
Misschien dat anderen er wat over kunnen zeggen?
De support van Synology is alles behalve slecht te noemen.
Daar kan menig bedrijf nog wat van leren.
Bericht door: Briolet op 07 januari 2016, 18:16:52
Bericht door: KeesZ op 07 januari 2016, 18:22:06
De limiet van 2GB is bekend bij Synology, maar blijkbaar zijn er maar weinig (support)medewerkers die dat weten.
Met de support heb ik echt alleen maar slechte ervaring, om een voorbeeld te noemen, ik heb gevraagd of het mogelijk is om de admin groep toegang te geven tot ftp maar de user groep niet. Het antwoord was dat dit niet kan en dat ik dan een aparte groep daarvoor moet aanmaken. Dat leek mij sterk dus heb ik de vraag nógmaals gesteld in een chatsessie. Ook daar kreeg ik te horen dat dit onmogelijk is. Vervolgens heb ik een nieuw ticket aangemaakt en nu kreeg ik ineens te horen dat dit wél mogelijk is: via configuratiescherm - rechten - klikken op ftp - bewerken - standaardmachtigingen - vinkje uitzetten, dat was alles en nu werkt het dus wél.
Bericht door: Briolet op 07 januari 2016, 18:27:03
(In https duurt het wel meer dan 2x zo lang als bij http, dus als codering niet belangrijk is, is het wel handig om de link even in http te veranderen.)
Maar gezien de plaatsing van het topic, werk je met beta software. Met DSM 5.2 is er volgens mij geen limiet.
Bericht door: KeesZ op 07 januari 2016, 18:30:59
Als je twee of meer bestanden gaat delen wordt er een zip-bestand van gemaakt, is dit groter dan 4GB dan is dit NIET uit te pakken op een Mac (met andere systemen heb ik geen ervaring).
Bericht door: Ben(V) op 07 januari 2016, 21:15:58
https://www.synology.com/en-us/knowledgebase/faq/387
De vraag is echter waarom je bestanden wilt uploaden via een mechanisme dat duidelijk bedoelt is voor het simpel snel delen van kleine bestanden.
Er zijn een aantal methoden die veel beter geschikt zijn voor dat doel.
Ik denk dat je het beste gewoon ftp kunt gebruiken, maar webdav,smbshare of cloudstation kunnen het ook allemaal.
Lees het manual eens over hun mogelijkheden en kies de methode die voor jouw doel het beste is.
Bericht door: Briolet op 07 januari 2016, 21:56:11
Uploaden via een afp share ging binnen 2 minuten, via hetzelfde netwerk. Dat geeft nog eens aan dat FileStation gewoon traag is in file transfer. Voor kleine files geen probleem, maar niet voor mega files.
Voor het vanaf het internet uploaden van mega-files zou ik zeker voor ftp of webdav kiezen.
Bericht door: KeesZ op 08 januari 2016, 11:04:13
De reden van het niet (kunnen) gebruiken van ftp o.i.d. is dat dit voor onze vaste en zeker nieuwe klanten nogal lastig en omslachtig is; er moet speciale software worden geïnstalleerd, ik moet per klant een account aanmaken, de klant heeft inloggegevens nodig en ik moet instructies geven over hoe zij hiermee moeten werken. De afgelopen jaren hebben wij gewerkt met WeTransfer en MyAirbridge en dat is enorm eenvoudig, geen inloggegevens nodig, supersnel en een bestandsgrootte tot 100 GB bij MyAirbridge. Kortom er is niets mis met deze methode.
De downloadlimiet van 4GB via een sharelink is natuurlijk ook belachelijk, maar vandaag kreeg ik een bericht dat ze dit aan het onderzoeken zijn. Ligt dit aan de beta-versie of heeft 5.2 dit probleem ook?
De snelheid van File Station en ftp ligt overigens bij ons beide gewoon op 200 Mbit/s, onze maximale snelheid dus dat maakt niets uit.
Kortom, als iemand nog een oplossing heeft dan hoor ik dat graag.
Bericht door: Hutje op 08 januari 2016, 11:24:00
Bericht door: Birdy op 08 januari 2016, 11:43:58
Bericht door: Ben(V) op 08 januari 2016, 15:24:57
Persoonlijk gebruik ik Filestation enkel als ik iets binnen de Nas van de ene share naar de andere moet kopieren en nergens anders voor.
Bericht door: KeesZ op 08 januari 2016, 17:35:05
Bericht door: Ben(V) op 08 januari 2016, 17:43:14
En simpel is een kwestie dat jij het goed moet inrichten.
Hier heb je bijvoorbeeld een link naar de ftp server van Tele2, kun je zo browsen en downloaden.
Denk niet dat dit te moeilijk is voor je klanten.
ftp://speedtest.tele2.net/
Bericht door: Briolet op 08 januari 2016, 18:11:07
[attachimg=1]
De default instelling is geregistreerde gebruiker, dus moet je zelf 'gast' kiezen en dan inloggen. Het wordt dan een share met 'read-only' rechten. Downloaden geen probleem. Voor downloaden kun je echter ook gewoon, met FileStation, een http(s) link naar een file of folder creëren. Dat download ook probleemloos grote files.
KeesZ wil klanten blijkbaar grote files laten uploaden. Op de mac heb je daar externe ftp software voor nodig. Of gewoon met WebDav, wat wel weer native is.
Bericht door: Ben(V) op 08 januari 2016, 18:35:43
Bij ja komt het bestand via ftp naar je toe.
Webdav werkt op een PC weer alleen met https en dan moet je weer een ceriticaat hebben.
Bericht door: KeesZ op 08 januari 2016, 20:06:20
Zoals ik al schreef is het zeer omslachtig om telkens voor elke klant een nieuw account aan te maken, dus webdav en ftp zijn daarom uitgesloten. Eén algemeen account gaat ook niet want dan kan Jan en alleman bij de (vertrouwelijke) bestanden.
Een link naar een folder groter dan 4Gb werkt ook niet, zoals ik al schreef wordt dit een onleesbaar zip-bestand.
Het enige wat ik wil is een hele simpele interface waarmee klanten 1 of meer grote bestanden kunnen uploaden zoals bijvoorbeeld wetransfer.nl (neem daar even een kijkje en verstuur een bestand a.u.b., eenvoudiger kán niet) Synology sales had mij verzekerd dat dit kon met de DS115 via file request (deze functie zit alleen op DSM 6.0), maar nogmaals, dit is door Synology gelimiteerd tot 2GB.
Het tweede simpele wat ik wil is een eenvoudige sharelink naar 2 of meer bestanden waarmee de klant zeer eenvoudig de bestanden kan downloaden. Voor 1 bestand werkt dit echt perfect maar meer bestanden kunnen niet worden ge-unzipt op een Mac indien ze groter zijn dan 4GB. Daarnaast komt de klant bij het downloaden van 2 of meer bestanden uit bij een onoverzichtelijk en voor hun onbekend File Station, in plaats van dat de bestanden onmiddellijk worden gedownload.
Ik hoop dat het nu duidelijk is.
Bericht door: Robert Koopman op 08 januari 2016, 20:10:03
In NL hebben we geen kantoor van Synology.
Bericht door: KeesZ op 08 januari 2016, 20:12:33
Bericht door: Ben(V) op 08 januari 2016, 20:28:26
Zijn nu eenmaal eigenwijze dingen die appleware.
Op een pc heb ik er in ieder geval geen last van.
Oplossing lijkt me overigens simpel, zip de bestanden zelf eerst met je mac en verstuurt ze daarna.
Bericht door: Briolet op 08 januari 2016, 20:41:12
…via file request (deze functie zit alleen op DSM 6.0),
Op zich vind ik het vreemd, zo niet fout, dat synology france naar een functie verwijst die nu alleen nog maar in beta software beschikbaar is. Alleen ontwikkelaars kun je dat adviseren, maar geen gewone gebruikers. Dit is dus blijkbaar een upload functie die ik niet ken.
Omdat anderen dit vast ook niet kennen hierbij:
In filestation is er een nieuwe optie bijgekomen: "Bestandsaanvraag maken". Dit geeft volgend scherm:
[attachimg=1]
Net als bij koppeling delen, kun je ook hier de link doorgeven aan derden. Als zij er dan op klikken in de browser (al dan niet via een mail mail), krijgen ze het volgende browserscherm:
[attach=2]
Hier kunnen ze de bestanden dan droppen. Dit kan zolang de link geldig blijft en ze komen in een eigen folder te staan. Dit is inderdaad gebruikersvriendelijk voor eenmalige acties waarvoor je geen accounts wilt aanmaken. Dan moet het natuurlijk wel werken.
Ik kan alleen maar zeggen dat dit beta software is en ze nooit beta software voor productie omgeving hadden mogen adviseren. Je kunt nu alleen bugmeldingen doen en hopen dat het over een paar maand in de final release opgelost is.
Bericht door: Briolet op 09 januari 2016, 12:15:49
[off-topic]
Nu weet ik weer waarom ik mijn 212j buiten gebruik gesteld heb en alleen nog voor backup gebruik: 'rete traag'. Maar daar staat wel de 6.0 beta op om te testen.
10GB zippen koste ruim meer dan een uur op die nas. (enkele minuten op mijn gewone nas). Downloaden via file station is ook belachelijk traag. Het duurde langer dan de afmeld-timer, waardoor de download afgebroken werd. In mijn opinie een bug, want een active download is geen inactiviteit en moet de verbinding in stand houden. Via een share was de zip wel binnen een paar minuten te downloaden.
[on-topic]
Bericht door: KeesZ op 09 januari 2016, 13:47:55
Overigens als ik eerst ga zippen (groter dan 4GB) via File Station en vervolgens een sharelink maak, dan kan de zip file wél ge-unzipt worden. Erg vreemd, blijkbaar zijn er twee zip-varianten/programma's op file-sation???
@Briolet ik heb je even privé bericht gestuurd met een link naar een paar files die groter zijn dan 4GB. Zou je voor mij eens kunnen kijken of je die kunt uitpakken? Misschien kan de unzipper van El Capitan hier wél mee overweg.
Ik ben het met je eens dat het fout is om een nieuwe gebruiker direct een beta versie te laten installeren, ik heb dus ook nooit met versie 5.2 gewerkt. Omdat zij 6.0 adviseerden ging ik er van uit dat deze versie zo goed als bugvrij zou zijn.
Is het overigens niet mogelijk om zelf de 2GB limiet aan te passen? Deze limiet moet natuurlijk "ergens" zijn vermeld in het systeem.
Bericht door: Briolet op 09 januari 2016, 16:25:27
Het zal nog een tijdje duren. Mijn download limiet is 100 Mbps, maar ik zie dat ik maar 0,5 Mbps haal.
[attachimg=1]
Ik gebruik normaal alleen de optie voor een enkele file. Bij een folder versie had ik niet onthouden dat er een optie was om alles in één keer te downloaden.
In je PB schreef je:
Citaat
De gofile link wordt overigens automatisch aangemaakt zodra ik een sharelink aanmaak, het zegt mij ook totaal niets waarom dit zo'n lastige naam is, ik had liever gehad dat onze bedrijfsnaam erin zou staan.
Gofile is alleen handig als je anoniem een link wilt doorgeven. In dit geval, bij een folder, kom ik toch op je nas uit met de ddns naam. Weg is de anonimiteit. Dan is het idd veel handiger om direct naar je ddns naam te linken. Of naar je bedrijfs url.
Volgens mij moet je in het configuratie scherm naar "Externe toegang" gaan en dan de tab "geavanceerd' kiezen. Als je daar je eigen url als hostnaam invult, krijg je die naam steeds in de links.
Ik had zelf graag de optie gehad om daarnaast nog steeds de gofile link te kunnen maken om files 'anoniem' door te kunnen geven.
Bericht door: KeesZ op 09 januari 2016, 16:42:35
Wat betreft de snelheid, binnenkort glasvezel, nu alleen 200/20 Mbit/s, maar die 20Mbit/s zou je dus sowieso moeten halen, 0,5 begrijp ik niet??? Enig idee hoe dit kan?
Misschien kun je via ftp dezelfde files eens downloaden en kijken welke snelheid je dan haalt? Inlog heb ik via pb naar je verstuurd.
Het laatste wat je schreef heb ik gedaan maar een sharelink blijft egofile.me
Bericht door: Briolet op 09 januari 2016, 18:29:32
Intussen ook één file met FTP (Cyberduck) opgehaald en die haalt iets van 14 Mbps. Dat is dan 70% van je upload capaciteit. Niet het maximum, maar toch redelijk.
Hoe de gofile.me selectie verloopt is voor mij een black box. En ik heb op dit forum ook nooit een éénduidig antwoord kunnen vinden. Vanaf het begin was mijn link altijd mijn IP/url. Op een dag kreeg ik plots een gofile.me link. Na wat geëxperimenteer met het invullen van het boven genoemde 'hostnaam' veld, had ik plots mijn url terug in de link. Echter, ik kon niet meer terug naar een gofile.me link door het 'hostnaam' veld weer leeg te maken.
Ik lees in de help nu wel dat het iets met Quick Connect te maken heeft. Misschien moet Quick Connect uit staan om die gofile.me links kwijt te raken. Anderzijds heb ik QC nog nooit actief gehad op mijn nas en toch heb ik die links ook kort gehad.
Bericht door: Ben(V) op 09 januari 2016, 18:38:37
Verder is ftp is voor dit soort grote bestanden altijd het efficients.
Bericht door: Briolet op 09 januari 2016, 18:55:23
Ik heb de zip nu. Geen 4.84 GB maar 5,19 GB na zippen. En inderdaad:
[attachimg=1]
Ook onder El Capitan weigert deze zip uit te pakken. Er zit iets in wat niet standaard is en de default unzipper niet herkent. Twee third-party unzippers, die ook mijn mac staan, pakken hem probleemloos uit: "The Unarchiver" en "Ez7z".
Bericht door: Ben(V) op 09 januari 2016, 19:06:54
Schijnt echt een mac issue te zijn met grote bestanden,de standaard mac unzip is gelimiteerd tot 2GB
Bericht door: Briolet op 09 januari 2016, 19:18:35
Bericht door: KeesZ op 09 januari 2016, 21:49:01
Andere unzippers pakken hem wel uit maar zoals ik al eerder schreef is het niet echt gebruiksvriendelijk om al onze nieuwe en bestaande klanten te verplichten om extra software te installeren. Daarnaast is dt een "fout" van Synology; zip-bestanden van bijvoorbeeld WeTransfer of MyAirbridge kunnen wél gewoon worden uitgepakt.
Ik heb dit 1 keer eerder mee gemaakt en wel bij Argeweb. Zij werken met Owncloud en zijn bekend met dit probleem maar kunnen hier zelf niets aan doen.
@Ben(V) dit is niet echt een Mac issue, grote zip-files van derden kan ik prima uitpakken. Alleen zip-files die tijdens het downloaden zijn gemaakt door File Station zijn niet uit te pakken. Als ik ze via File Station eerst ga zippen en vervolgens een sharelink aanmaak kan ik ze wél uitpakken, maar het zippen kost dan enorm veel extra tijd.
FTP is niet echt een optie zoals ik al eerder schreef. Nogmaals, voorheen werkten wij met WeTransfer en MyAirbridge en dat werkt gewoon érg goed, makkelijk en snel, maar doordat de filmbestanden steeds groter worden zijn we gedwongen om uit te wijken naar een ander systeem. Aangezien ik geen bedrijf heb kunnen vinden die deze diensten werkend aanbiedt (ik heb 27 testaccounts gehad bij diversen bedrijven) zijn we noodgedwongen overgestapt op een NAS, mede door het advies van Synology.
Misschien kunnen jullie mij een plezier doen en deze bug melden bij Synology; hoe meer mensen dit melden hoe groter de kans is dat dit wordt hersteld.
Bericht door: Ben(V) op 09 januari 2016, 22:53:55
Ik vind geen enkele melding van het niet kunnen uitpakken van door Synology gemaakte zip bestanden buiten een mac om.
En als alle derde partijen het wel kunnen uitpakken lijkt het met toch echt een mac issue,.
Helaas heeft een issue melden bij apple nooit resultaat.
Bericht door: KeesZ op 10 januari 2016, 00:06:11
Waarschijnlijk heb ik het onduidelijk uitgelegd: van de 27 testaccounts die ik heb gehad konden er 26 bedrijven grote zip-files maken die keurig netjes konden worden uitgepakt door een Mac, het enige bedrijf waar dit niet kon was Argeweb, en nu dus ook Synology. Verder heb ik ook nooit problemen gehad met zip-files, vandaar dat ik dit geen Mac issue noem.
Overigens heb ik in mijn allereerste post al gemeld dat dit probleem alleen op een Mac voorkomt, dus dat hoeft natuurlijk niet opnieuw bewezen te worden, ik zoek juist een oplossing hiervoor. De sales van Synology gaf aan dat dit gewoon zou kunnen en zij zaten daar finaal naast, ik noem dat onkunde en zij komen niet met oplossingen, vandaar mijn vraag op dit forum.
Bericht door: Stephan296 op 10 januari 2016, 00:46:37
Bericht door: Ben(V) op 10 januari 2016, 09:15:07
Het lijkt erop dat er een nieuwe zip versie is, de zogenaamde zip64 extensie die nodig is om file's groter dan 4GB te kunnen zippen en unzippen.
Deze versie wordt (nog) niet ondersteund door de native unzipper van de mac.
Een stukje uit de wiki.
Citaat
The File Explorer in Windows XP does not support ZIP64, but the Explorer in Windows Vista does.[citation needed] Likewise, some extension libraries support ZIP64, such as DotNetZip, QuaZIP[29] and IO::Compress::Zip in Perl. Python's built-in zipfile supports it since 2.5 and defaults to it since 3.4.[30] OpenJDK's built-in java.util.zip supports ZIP64 from version Java 7.[31] Android Java API still does not support ZIP64.[32] OS X Yosemite does support the creation of ZIP64 archives, but does not support unzipping these archives using the graphical Archive Utility
Het rare van het verhaal is dat op een mac de zip64 functie wel schijnt te werken maar de unzip64 niet.
Overigens is dit niet mijn kennis, maar als je even googled naar "mac unzip problems larges files", dan struikel je bijna over de vele reacties van mensen die dit ook ervaren.
Om nu Synology sales de schuld te geven dat apple het zip64 formaat niet ondersteund lijkt mij niet correct.
Wel zou Synology sales geen functionaliteit moet verzekeren die nog slechts in een beta versie beschikbaar is zonder dat erbij te vermelden (maar misschien hebben ze dat wel gedaan).
Bericht door: KeesZ op 10 januari 2016, 10:31:17
@Ben(V) Ik ben dit probleem probleem alleen tegengekomen bij Argeweb en Synology zoals ik al schreef, verder ben ik dit nooit eerder tegengekomen. Ook schreef ik al eerder dat wanneer ik zelf handmatig ga zippen via File Station (maar dat duurt een paar uur dus niet te doen) dat de klant deze zip-file probleemloos kan uitpakken, het probleem treedt alleen op bij het sharen van een file via FileStation, dan wordt er blijkbaar andere zip-software gebruikt die niet compatible is.
Bericht door: Briolet op 10 januari 2016, 12:10:47
Code: [Selecteer]
Briolet$ zipinfo -1 ~/ScanCoveryTrial.zip
[~/ScanCoveryTrial.zip]
error: End-of-centdir-64 signature not where expected (prepended bytes?)
(attempting to process anyway)
warning ~/ScanCoveryTrial.zip]: 896679025 extra bytes at beginning or within zipfile
(attempting to process anyway)
De structuur is dus anders dan verwacht. Misschien dat de nas hier een te nieuw protocol gebruikt, maar de mac kan dergelijke files doorgaans toch gewoon unzippen. Ik denk dat er hier iets anders speelt. Als ik naml. vanuit de terminal probeer te unzippen, lukt dat voor 11 van de 13 files:
Code: [Selecteer]
Briolet$ unzip ~/ScanCoveryTrial.zip
Archive: ~/ScanCoveryTrial.zip
error: End-of-centdir-64 signature not where expected (prepended bytes?)
(attempting to process anyway)
warning [~/ScanCoveryTrial.zip]: 896679025 extra bytes at beginning or within zipfile
(attempting to process anyway)
file #1: bad zipfile offset (local header sig): 896679025
(attempting to re-compensate)
creating: ScanCoveryTrial/
extracting: ScanCoveryTrial/C0011.mov
extracting: ScanCoveryTrial/C0012.mov
extracting: ScanCoveryTrial/C0029.mov
extracting: ScanCoveryTrial/C0053.mov
extracting: ScanCoveryTrial/C0055.mov
extracting: ScanCoveryTrial/C0062.mov
extracting: ScanCoveryTrial/C0063.mov
extracting: ScanCoveryTrial/C0077.mov
extracting: ScanCoveryTrial/C0080.mov
extracting: ScanCoveryTrial/C0081.mov
extracting: ScanCoveryTrial/C0083.mov
file #13: bad zipfile offset (local header sig): 4294967295
(attempting to re-compensate)
file #13: bad zipfile offset (local header sig): 4294967295
file #14: bad zipfile offset (local header sig): 5191646320
Pas bij de laatste 2 files komt hij nog een fout tegen bij deze zip.
De terminal valt pas over de files als hij ze tegenkomt, de finder begint al niet aan de extractie.
Bericht door: Briolet op 10 januari 2016, 12:27:47
Als ik een zip door FileStation met zipinfo bekijk dan is het compressie formaat "defN", Dat is hetzelfde formaat wat de mac ook gebruikt. De file die ik van Kees kreeg was echter via een link gedownload. Daar hebben de files het compressie formaat "stor", wat betekend dat er geen compressie gebruikt is. Alleen een bundeling tot een zip.
Code: [Selecteer]
-rwxrwxrwx 3.0 unx 517539765 bX 517539765 stor 15-Dec-23 21:04 ScanCoveryTrial/C0055.movUit de zipinfo manual:
Citaat
Finally, the seventh field indicates the compression method and possible sub-method used. There are six methods known at present: storing (no compression), reducing, shrinking, imploding, tokenizing (never publicly released), and deflating. In addition, there are four levels of reducing (1 through 4); four types of imploding (4K or 8K sliding dictionary, and 2 or 3 Shannon-Fano trees); and four levels of deflating (superfast, fast, normal, maximum compression). zipinfo represents these methods and their sub-methods as follows: stor; re:1, re:2, etc.; shrk; i4:2, i8:3, etc.; tokn; and defS, defF, defN, and defX.
Dus standaard gebruikt de Nas defN wat betekent "deflating normal"
Het tweede nummer 3.0 is overigens het versienummer van de zipper. De nas gebruikt hier v3.0 en de mac v2.1. Apple is doorgaans conservatief met het gebruiken van nieuwere versies.
Dit zegt niets over de versie van de unzipper. De mac gebruikt:
Code: [Selecteer]
UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.
En de nas:Code: [Selecteer]
UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.
Zelfde versie, maar vreemd dat er dan een andere naam bij staat.
Bericht door: Briolet op 10 januari 2016, 12:43:35
De nas geeft:
Code: [Selecteer]
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
Zip 3.0 (July 5th 2008).De Mac geeft:
Code: [Selecteer]
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
Zip 3.0 (July 5th 2008).Dat is dus identiek. In de terminal gebruikt de mac dus versie 3.0 van de zipper en als ik in de finder zip, vind ik versie 2.1 terug als gebruikte versie. (waarschijnlijk wordt hier de oude versie gebruikt om zoveel mogelijk compatibel te blijven met andere computers)
Bericht door: Briolet op 10 januari 2016, 13:47:38
Het lijkt erop dat er een nieuwe zip versie is, de zogenaamde zip64 extensie die nodig is om file's groter dan 4GB te kunnen zippen en unzippen.
Deze versie wordt (nog) niet ondersteund door de native unzipper van de mac.
Klopt, maar dit is hier niet het probleem als ik de officiële releasenotes (http://www.info-zip.org/UnZip.html) van UnZip 6.0 doorlees:
Citaat
New features in UnZip 6.0, released 20 April 2009:De 4GB grens is niet die van de zipfile, maar van individuele entries.
• Support PKWARE ZIP64 extensions, allowing Zip archives and Zip archive entries larger than 4 GiBytes and more than 65536 entries within a single Zip archive. This support is currently only available for Unix, OpenVMS and Win32/Win64.
Ik heb de zip ook naar de nas verplaatst en ook daar met UnZip 6.0 unzipped. Dat loopt probleemloos. Ik krijg geen foutmeldingen en ook de laatste 2 files unzippen zonder waarschuwing.
De mac versie van unzip 6.0 geeft wel foutmeldigen.