geplaatst door: doctor_apple
Daar zijn we weer  :wink: ...

Zit met het volgende probleem waar ikzelf niet helemaal uitkom. Mogelijk is hier een Mac-guru die hier een passend antwoord heeft.

[ Wat/Waarom ]

Interoperabiliteit tussen Linux <> Windows <> macOS van de bestandssystemen. Probleem is (zoals zo vaak): data van omgeving a naar b te krijgen zonder kleerscheuren. Ik heb veel data op relatief 'besturingssysteem neutrale' bestandssystemen, zoals bijvoorbeeld exfat. Maar, ik heb natuurlijk ook de nodige (voor mij belangrijke) data op OS-specifieke schijven, waaronder XFS, ext4, NTFS en (legacy) HFS+.

Na een avondje te hebben gevochten met het maken van goede backups van Catalina en Big Sur vanaf de prompt (hetgeen uiteindelijk perfect gelukt is - maar wel met de nodige irritaties en rariteiten), is de volgende uitdaging dus de data migratie.

[ Probleem ]

Als ik bestanden kopieer van NTFS naar APFS dan krijg ik synchronisatiefoutmeldingen dat bestanden niet gelezen kunnen worden. De synchronisatie wordt dan ook "hardcore" op OS niveau afgekapt. Of ik nu een (gratis) tool FreeFileSync gebruik, de Finder, rsync of wat dan ook: het faalt.

Hierop eens verdiept op welke bestanden het nu precies foutloopt en dat zijn bestanden met bijzondere leestekens.

/Volumes/NTFS/Persoonlijk Archief/Dossier Benelux/Financie?\#210n
Wat natuurlijk had moeten verschijnen is:
/Volumes/NTFS/Persoonlijk Archief/Dossier Benelux/Financiën )

rsync geeft onherroepelijk: IO error encountered

Bij andere bestanden met bijzondere leestekens krijg ik het volgende:

file has vanished: "/Volumes/NTFS/Persoonlijk Archief/Dossier Curaçao/Financiën"
 :cry:

[ Achtergrond Info ]

Ik heb hierop gedacht dat het aan de NTFS-driver kon liggen, dus heb ik Tuxera NTFS aangeschaft. Goed, de synchronisatie gaat inderdaad iets sneller dan voorheen, maar ... hetzelfde probleem.

Toen heb ik bedacht om eens te kijken naar rsync zelf, een klein sneer naar Apple: die is potverdorie al vijftien jaar niet bijgewerkt. De hele unix-core van macOS is op vele punten antiek: ook in Big Sur. Men is helemaal niet met de tijd meegegaan. Ontbreken dus ook heel veel opties, mogelijkheden en meer. Maar goed, genoeg ge!@# ... dus homebrew geïnstalleerd, rsync bijgewerkt tot een wat courantere versie om middels de optie '--iconv' namen 'on the fly' te kunnen converteren.

Maar ook hier, helaas.

Dus ik heb een courante versie van Windows 10 gepakt, een lege schijf opnieuw gepartitioneerd, geformatteerd en vervolgens de data opnieuw gekopieerd. Om zeker te zijn dat er niets met de schijf of bestandssysteem aan de hand zou zijn. Ook direct de checksums doorlopen aan de hand van controlelijsten: alle checksums kloppen. Omdat het hier toch om wat data gaat (225 gigabyte), bracht dit niet direct een glimlacht op het gezicht. Maar goed.

Vervolgens Linux opgestart en getest of ik de data kan overzetten. Dat ging probleemloos, maar ... geen goede ondersteuning voor APFS en al helemaal niet voor Filevault.

Dus terug naar macOS, daar de schijf aangekoppeld en ... ja hoor ... daar zijn we weer: ongeveer 5 tot 10% van de bestanden geeft fouten. Omdat het over de 150'000 bestanden zijn bij elkaar heb ik niet bepaald zin om daar handmatig dingen te doorlopen. Voor een test mijn multimedia archief erbij gepakt (Linux XFS formaat). MacFuse met XFS support aangekoppeld en verdikkeme: soortgelijk probleem met mijn archief met Nepalese trommeltjes en belletjes tot en met courante popmuziek en alles ertussenin. Aziatische namen (Japans en Chinees bijvoorbeeld) geven weinig problemen, maar Latijnse bijzondere leestekens weer wel  :blink:

[ Vraag ]

Wie weet hoe ik probleemloos van NTFS naar APFS bestanden kan overzetten vanuit macOS zelf zonder dat ik bang hoef te zijn dat er zaken 'achterblijven'. Meerdere tools geprobeerd (finder, freefilecopy, rsync en nog enkele unix-tools) maar niets helpt.

Overigens lijkt het doel-bestandssysteem (vooralsnog) niet heel voel toe te doen, omdat het probleem echt lijkt te zitten in het lezen van de bestanden. Zoals aangegeven: Linux en Windows begrijpen elkaar met betrekking tot NTFS beter.

Exfat als bestandssysteem heb ik nog niet geprobeerd, ga ik zometeen proberen, maar heb een vermoeden dat het echt in de bestandsnamen zit. Omdat er ook een hoop gedeelde bestanden zitten (waarbij de consistentie van namen zeer belangrijk is voor het synchronisatieproces) kan ik niet de namen zomaar gaan aanpassen. Vandaar ook natuurlijk dat ik graag met rsync had willen werken  :wink:.

Overigens een kanttekening: rclone geprobeerd met zowel Google Drive en one drive en tijdens het synchroniseren (na het valideren middels een controlelijst (checksums)) blijken diverse bestanden te worden genegeerd bij het synchroniseren. Zoals je waarschijnlijk aan je water kunt voelen: bestanden met meerdere leestekens of bepaalde combinaties (waaronder natuurlijk de dubbele punt).

Wie kan hiermee helpen?

antw: Bestanden kopiëren en synchroniseren van/naar Mac
19 januari 2021 - 09:50    reactie #1
geplaatst door: Kapotlood
Als het je puur om bestandsdeling/synchronisatie te doen is, is een "tussenpartij" dan niet een makkelijke oplossing? Zoals een NAS bijvoorbeeld? Dan kun je namelijk prima zelf via diverse oplossingen bestanden over en weer syncen.

Bijvoorbeeld via OwnCloud op zowel de computers als de NAS. Of door gewoon vanaf de NAS te werken vanaf beide systemen. En vast nog wel meer wat mogelijk is. Dat voorkomt programma's die je moet opzoeken en die wellicht bestanden achterlaten zoals je zei :)
antw: Bestanden kopiëren en synchroniseren van/naar Mac
19 januari 2021 - 10:50    reactie #2
geplaatst door: doctor_apple
Dat zou een oplossing kunnen zijn. Maar er gaat niets boven DAS opslag in snelheid. Daarnaast heb ik vannacht eens wat nader onderzoek gedaan en ben een beetje geschrokken hoe bepaalde zaken in macOS worden afgehandeld ten aanzien van File IO.

Waarom? Eenvoudig er ontbreken basale zaken in het bestandssysteem, zoals dataintegriteit op bestandsniveau (foutcorrectie).

Foutcorrectie kan namelijik in het bestandssysteem worden opgenomen, zoals het geval is bij Btrfs (Linux) en ZFS (platformonafhankelijk). Dit omvat een proces van ‘data scrubbing’ waarbij het bestandssysteem wordt gescand om fouten op te sporen en te proberen deze te herstellen. Noch HFS + noch APFS proberen enige vorm van foutcorrectie op opgeslagen gegevens, en Apple heeft ook niet aangekondigd dat APFS dit ooit zal doen.

Als foutcorrectie voor de Mac-gebruikers niet toegankelijk is op bestandssysteemniveau en er geen systeemondersteuning is voor integriteitscontrole van bestanden, is de enige manier om deze problemen op te lossen het gebruik van producten van derden.

Dat was de reden dat ik was begonnen met het maken van simpele checksum lijsten.

find / -type f -exec shasum -a 256 {} \; | tee Check.sha | awk {'print $2'}
Vanaf de terminal. Daarmee krijg je een lijst in de vorm van:

/usr/bin/uux
/usr/bin/cpan5.18
/usr/bin/BuildStrings
/usr/bin/loads.d
/usr/bin/write
/usr/bin/indent
/usr/bin/bzip2recover
/usr/bin/hdiutil
/usr/bin/top
/usr/bin/pstruct5.18

totdat alles is doorlopen.

Kijk je in het bestand, dan zie je:

06c747d53960d7926f7dc369e56c571bf84b34073c4db7d246d96a7d447cc42a  /usr/bin/uux
9b47268e74371721d4942b31d6ddfef7892b88d37783dad6695fbfc2c0a18242  /usr/bin/cpan5.18
0979fb2d50f26cdfd688399e31b6be213b1b0dc81eb686f28d5cd22e4cdd3022  /usr/bin/BuildStrings
8e3b439715a266d19bef28969d22eb738923f6f210b677ed63c63437b34989e3  /usr/bin/loads.d
16a9927345c4624f0f7bd593ac9b6f2493cda8e060a37946dbb8ee42dca74816  /usr/bin/write
fa2054691e279ebbb948c97d5b89d8d05b649762cc59e39f2f8d9ebb20de270f  /usr/bin/indent
... etc

Geef je vervolgens in:

shasum -c Check.sha
Dan krijg je een lijst:

/usr/bin/uux: OK
/usr/bin/cpan5.18: OK
/usr/bin/BuildStrings: OK
/usr/bin/loads.d: OK
/usr/bin/write: OK
/usr/bin/indent: OK
/usr/bin/bzip2recover: OK
/usr/bin/hdiutil: OK
/usr/bin/top: OK
/usr/bin/pstruct5.18: OK
/usr/bin/tee: OK
/usr/bin/binhex5.18.pl: OK
/usr/bin/xip: OK
/usr/bin/bzfgrep: OK
/usr/bin/snmptranslate: OK
/usr/bin/split: OK
/usr/bin/chsh: FAILED

... etc ...

Als je nu de volgende regel ingeeft:

shasum -c test.sha | egrep -v "OK"
Dan zul je enkel bestanden krijgen die niet meer overeenkomen met de checksum.

Wat wil nu het feit. In het verleden was gebleken dat bestanden na verloop van tijd niet meer overeenkwamen met de checksums. Ook niet in Timemachine. Kennelijk was er sprake van - wat ik later leerde kennen onder de term: - bitrot (of data rot).

Een goed voorbeeld hiervan is te vinden bij wikipedia:

Oorspronkelijke foto



Slechts 1 bitje anders (geval van bitrot):



dus ben ik verder op onderzoek gegaan en kwam toen tot de volgende ontdekking:

Decomposition (NFD), dwz Duitse umlauts worden bijvoorbeeld opgeslagen als twee tekens ("ä" "-> a, U + 0308). Bij het synchroniseren met een NTFS wordt deze decompositie ook gesynchroniseerd , dus umlauts worden ook opgeslagen in NFD, terwijl het bronbestandssysteem in NFC wordt opgeslagen ("ä" als één enkel teken U + 00E4).

Apple heeft ervoor gekozen om de UTF-8 normalisatie om een hybride systeem te gebruiken (NFD en NFC) voor het normaliseren van UTF-8.

Het onderscheid veroorzaakt complexiteit en vaak problemen bij software die gegevens deelt tussen Apple-platforms en andere platforms, zoals bijvoorbeeld versiebeheersystemen en in dit geval: bestandssysteem.

Unicode Normalisation is dus de grondslag voor de problemen. Een regelrecht drama. Ben nu nog steeds op zoek naar een oplossing daar dit probleem dus ook zal spelen met cloud-storage. Enig onderzoek heeft aangetoond dat ook Google over dit probleem schrijft. Dus het probleem is niet nieuw.

Een NAS zou kunnen helpen, maar feitelijk zorgt de software voor de UTF NFD/NFC normalisatie van de tekens. Overigens, voor het geval je je afvraagt, waar heeft de beste man het over, heb ik een leuk voorbeeld gevonden op het internet:

Een shell-script:

$ cat .x
u="Böhmáí"
touch "$u"
ls > .list
echo "$u" >.text

cat .list .text
diff .list .text
od -bc .list
od -bc .text



als dit script wordt uitgevoerd met sh -x .x

$ sh -x .x
+ u=Böhmáí
+ touch Böhmáí
+ ls
+ echo Böhmáí
+ cat .list .text
Böhmáí
Böhmáí
+ diff .list .text
1c1
< Böhmáí
---
> Böhmáí
+ od -bc .list
0000000   102 157 314 210 150 155 141 314 201 151 314 201 012           
           B   o   ̈    **   h   m   a   ́    **   i   ́    **  \n           
0000015
+ od -bc .text
0000000   102 303 266 150 155 303 241 303 255 012                       
           B   ö  **   h   m   á  **   í  **  \n                       
0000012

... in bovenstaand voorbeeld kun je zien dat hoewel de text in de terminal hetzelfde zal lijken, dat deze feitelijk ANDERS wordt opgeslagen en verwerkt in het systeem.

Alles heeft natuurlijk een (historische) reden, maar dit is iets wat naar mijn beleving best eens wat meer werk van gemaakt mag worden aangezien het echt voor problemen kan zorgen, ook met cloud-oplossingen.

Nu is UTF-8 normalisatie en data integriteit niet een en hetzelfde. Maar er is dus wat mij betreft wel een probleem met twee belangrijke zaken op FS niveau.

...

Er is mij via een ander forum gevraagd of ik verbitterd ben inzake Apple, daar ik geregeld kritische en soms zelfs verbitterd klinkede posts schrijf over Apple.  :happy:

Neen is het antwoord: ik heb alleen niet alleen al het zoet van Apple mogen ervaren, maar ook het zuur. Waarbij ik met de jaren dingen 'gewoon was gaan vinden'. Zoals het moeten spelen met de terminal om simpele zaken aan of uit te krijgen of zaken te fixen. Hoort namelijk eigenlijk niet.

Hoewel nog steeds fan van Apple ben ik absoluut kritisch inzake bepaalde ontwikkelingen; zeker als ik bij de buren heb gezien dat het anders kan. Of ... omdat ik vanuit mijn eigen kennisgebied WEET dat dingen ook anders KUNNEN. Onderzoek heeft mij getoont dat bestandsbeheer op macOS gewoon niet betrouwbaar is. Aanname dat alles 'wel zal werken' en 'goed wordt gesynchroniseerd' en 'goed opgeslagen wordt' is niet gestaafd op feiten. Ja, vaak gaat het goed. Soms gaat het 'ogenschijnlijk goed', oftewel: heeft de gebruiker geen weet van. Heb tests gedaan tussen HFS+ en APFS en wat blijkt: APFS gaat heel anders om met bestandsnamen dan de HFS+ implementatie. In dat geval is het veel minder zichtbaar, maar zo kan het gebeuren dat een bepaalde bestandsnaam tijdens het overzetten ' van naam veranderdt ' (lees: codering onder water) wat toch echt problemen kan opleveren bij het zoeken naar dit bestand.

Ik zal kijken of ik een oplossing kan vinden, maar nu ik dit weet ben ik toch wat huiverig om kerngegevens weer naar macOS over te brengen. Momenteel zitten ze op een gedeelde Linux/Windows omgeving sinds dat ze enkele jaren terug van MacOS X zijn gemigreerd. Validaties hebben mij laten zien dat er 0,0% aan data verloren is gegaan sindsdien. En ook hier is de bron van de data soms NTFS, soms ExFAT, soms XFS, soms Ext4, soms zelfs HFS+ of APFS ... Simpel iets kopieren naar Linux vormt eigenlijk nooit echt een probleem (in mijn ervaring). Problematisch zijn Bitlocker en Filevault om die te lezen. Maar nu omgekeerd de data naar macOS moet vanaf een NTFS partitie lijkt dit dus niet zondermeer te kunnen.

Als ik de normalisatiemechanismes van de NAS zou achterhalen, dan kan dit natuurlijk ook native op macOS - daarvan ben ik overtuigd. Alleen jammer dat zoiets simpels zo lastig moet zijn.

Ik ga verder op zoek naar een oplossing :wink:

Het moet toch mogelijk zijn op een betrouwbare oplossing onder macOS werkend te krijgen, toch?  :dontgetit:
antw: Bestanden kopiëren en synchroniseren van/naar Mac
19 januari 2021 - 10:54    reactie #3
geplaatst door: Flix
Zoals altijd lukt het je niet om iets kort en bondig op te schrijven, en verval je in een warrig verhaal waar ik geen chocola van kan maken.

Algemeen: als je bestanden via het netwerk overbrengt, heeft formattering geen enkele invloed op het bestand. Voor synchronisatie zal het wat ingewikkelder liggen, maar daarvoor pak je tegenwoordig toch een clouddienst? Of je zet je eigen 'clouddienst' op via een NAS?

Edit: ik noem dit als algemene opmerking voor anderen, want het is duidelijk dat TS zijn eigen verhaal heeft. :cool:
antw: Bestanden kopiëren en synchroniseren van/naar Mac
19 januari 2021 - 11:07    reactie #4
geplaatst door: MacFrankie
Beste doctor,

Filenamen met "bijzondere tekens" erin (niet-ASCII tekens, dus tekens die buiten de range 32-127 van de 8-bits karakterset vallen) worden op verschillende systemen verschillend gecodeerd. Helaas.

Er zijn verschillende (ISO) karaktersets, en daarbinnen nog verschillende (Unicode) coderingen. De omzetting van de ene naar de andere gaat niet altijd probleemloos.

Via deze link zie je hoe je bestanden van de ene naar de andere codering kunt overzetten. Mogelijk is iets soortgelijks te doen met de bestandsnamen.

Maar misschien is het ook mogelijk om een DAS als NAS te benaderen door de schijf te delen en via localhost te benaderen. Dan zorgt de file server stack misschien al voor de juiste vertaling.
Op mijn werk heb ik al Windows, thuis wil ik geen systeembeheerder meer zijn!
antw: Bestanden kopiëren en synchroniseren van/naar Mac
19 januari 2021 - 11:21    reactie #5
geplaatst door: MacFrankie
Zoals altijd lukt het je niet om iets kort en bondig op te schrijven, en verval je in een warrig verhaal waar ik geen chocola van kan maken.
Dat klopt. Er is (volgens mij) één hoofdprobleem, karaktercodering van filenamen bij file synchronisatie, en het verhaal eromheen is niet een verduidelijking maar een verzameling los gerelateerde problemen en onderzoeken.

Vervolgens, duiveltje uit een doosje, komt er een tweede probleem bij, data integriteit van Mac filesystemen.

@doctor_apple:
Advies: maak twee discussies, één waar je kort en bondig het probleem van de filesynchronisatie schetst, plus daarbij voorbeelden en wat je allemaal hebt geprobeerd om het op te lossen, en één waar je het probleem van de data-integriteit aan de orde stelt. Dat maakt het allemaal wat beter leesbaar.

Nog iets anders, macOS kan standaard niet schrijven naar een NTFS volume. Deze schijf hangt dus gewoonlijk aan een andere computer. Wat nou als je op al je computers een standaard cloud-dienst gebruikt om bepaalde mappen te synchroniseren. Dan gaat het ongemerkt, incrementeel, is een hogere DAS snelheid niet meer van belang, en hoef je niet continu je schijven om te prikken. Clouddiensten die op alle platformen werken en de synchronisatietools hebben zijn oa Google Drive, Box, DropBox, ..., of je eigen NAS.
Op mijn werk heb ik al Windows, thuis wil ik geen systeembeheerder meer zijn!
antw: Bestanden kopiëren en synchroniseren van/naar Mac
19 januari 2021 - 17:22    reactie #6
geplaatst door: boiing
Algemeen: als je bestanden via het netwerk overbrengt, heeft formattering geen enkele invloed op het bestand.
+1.

En @doctor_apple: het bit-rot verhaal is interessant maar ook off-topic in je eigen topic. Hulde voor je onderzoek en diepte-analyse maar je mist de grote lijnen. 'Bit-rot' is zeldzaam, er zijn allerlei redenen waarom Apple niet aan bestand-checksums doet en er zijn nadelen (allemaal te googelen). Bovendien leg je de focus bij Apple (alsof ze iets héél belangrijks nalaten..) maar NTFS, exFAT en ext4 doen ook niet aan foutcorrectie op bestandsniveau.

Je conclusie 'onderzoek heeft mij getoont [sic] dat bestandsbeheer op macOS gewoon niet betrouwbaar is' lijkt stoer omdat je zoveel tekst produceert en dan oogt het al snel waar voor de 'casual reader' (mochten ze zich er doorheen geworsteld hebben :happy:). Maar serieus: waar koppel je die conclusie nou aan? Het bit-rot verhaal of het bestandsnamen probleem? Het eerste geldt ook voor Windows en de meeste Linux systemen, en het tweede heeft met een NTFS vs HFS+/APFS incompatibiliteit te maken. Ik concludeer dat jouw conclusie niet klopt.

Bewerkt: 19 januari 2021 - 18:05 door boiing
antw: Bestanden kopiëren en synchroniseren van/naar Mac
19 januari 2021 - 18:19    reactie #7
geplaatst door: Max Gaav
Disclaimer: Ik mis de technische kennis om inhoudelijk mee te kunnen praten. Bij deze dus een lekensuggestie.

Een tijd geleden had ik gedoe met een van mijn cloudservices, t.w. Sync.com. Het bleek dat niet alle tekens goed werden weggeschreven. Hierbij het overzicht van Sync. Ik moest dus mijn Mac scannen op 'foute' bestandsnamen.

Als je weet wat de beperkingen van elk van de door jou gebruikte platforms zijn, waarom maak je dan niet een handleiding voor jezelf met wat in benamingen wel/niet kan? Dan zit je altijd op alledrie je platforms save.

Dat handmatig doorlopen/veranderen van bestandsnamen is niet nodig als je zoiets als A Better Finder Rename gebruikt op de Mac. Zoiets is er natuurlijk ook voor Windows en Linux. Het is vast ook met de respectievelijke terminals te regelen.

Waarschijnlijk al bekend: Filename encoding and interoperability problems (Google).
Bewerkt: 19 januari 2021 - 18:46 door Max Gaav
My Mac is my second brain.
antw: Bestanden kopiëren en synchroniseren van/naar Mac
19 januari 2021 - 20:01    reactie #8
geplaatst door: doctor_apple
+1.

En @doctor_apple: het bit-rot verhaal is interessant maar ook off-topic in je eigen topic. Hulde voor je onderzoek en diepte-analyse maar je mist de grote lijnen. 'Bit-rot' is zeldzaam, er zijn allerlei redenen waarom Apple niet aan bestand-checksums doet en er zijn nadelen (allemaal te googelen). Bovendien leg je de focus bij Apple (alsof ze iets héél belangrijks nalaten..) maar NTFS, exFAT en ext4 doen ook niet aan foutcorrectie op bestandsniveau.

Klopt, voor wat betreft NTFS en Exfat, niet voor Ext4. NTFS 3.1 dateert van 2001 en zou best eens opgevolgd mogen worden. ExFAT is bedoeld als vervanger van FAT en voornamelijk voor externe media, daar zitten geen zaken als ACL's, extra bits of andere soortige in.

APFS is hagelnieuw en een kans om zaken anders te doen. Ja, ik ben met je eens dat foutcorrectie rekenkracht kost. Maar nu even serieus: zelf op m'n suffe Lenovo staat het apparaat merendeels van de tijd bijna idle, de GPU draait op hooguit 2% totdat ik een intensief programma opstart. Ik geloof niet dat dit met huidige rekenracht nog echt van toepassing is. Daarnaast merk ik onder Linux met ZFS niet heel veel aan extra verloren rekenkracht.

Ik vermoed dat het eerder ging om schaalbaarheid van Apple Watch -> Workstation. Op embedded devices is de impact van filebased checksums natuurlijk zichtbaar. MAAR, het was mooi geweest als hiervoor een optie ingebakken zou zijn geweest.

Ben eens dat bit rot niet dagelijks voorkomt. Maar nu een tweede reality check. Alle volumes bij elkaar (en daar zitten dus ook disk images, home movies, muziek bibliotheek, zakelijke archieven, etc) kom ik echt op TERABYTES aan data. Foutjes sluipen er altijd ongemerkt in. Ikzelf werk met het principe van checksums en gespiegelde kopieen. Van elke externe SSD of USB is er een broer of zus met exact dezelfde kopie die periodiek wordt bijgewerkt. Echter, voordat dit gebeurd wordt eerst getoetst of de checksums nog kloppen, of er geen rariteiten zijn in de structuur en DAN PAS gaan we transacties (lees: wissen, updaten, wegschrijven, etc) uitvoeren.

Waarom? Omdat ik door schade en schande redelijk wat data door de jaren kwijt ben geraakt. Ironisch genoeg op MacOS, MacOS X en macOS ... Hoofdelijk omdat dit jarenlang mijn hoofdplatform was, maar terugkijkend met de technische kennis van nu is HFS en later HFS+ geen wonderkind om nog te zwijgen van vroege OS releases met de nodige (Desastreuse) bugs.

Houd nog steeds van Apple, maar heb daardoor wel nogal een trauma te verwerken gehad.

Behalve persoonlijk leed (verloren foto's en video's van overleden personen) heeft het me zakelijk de nodige ergernis en bakken met geld gekost. Vandaar soms de bittere ondertoon ... Maar ik ben van mening dat er ook veel goeds zit bij Apple, dus helemaal afscheid nemen lukt niet. Wil ik ook niet. Maar kritisch blijven? Ja dat zeker!


Je conclusie 'onderzoek heeft mij getoont [sic] dat bestandsbeheer op macOS gewoon niet betrouwbaar is' lijkt stoer omdat je zoveel tekst produceert en dan oogt het al snel waar voor de 'casual reader' (mochten ze zich er doorheen geworsteld hebben :happy:). Maar serieus: waar koppel je die conclusie nou aan? Het bit-rot verhaal of het bestandsnamen probleem? Het eerste geldt ook voor Windows en de meeste Linux systemen, en het tweede heeft met een NTFS vs HFS+/APFS incompatibiliteit te maken. Ik concludeer dat jouw conclusie niet klopt.

Ervaring ... Het is lock-down, heb even de tijd om wat prive dingen te doen en heb hier dus (zoals in een ander bericht) geschreven twee machines op het bureau as we speak: een ThinkStation P330 van Lenovo met Linux en Windows en een Mac Mini 2018 met twee systemen: Catalina en Big Sur.

Zou graag weer een tijdje onder macOS werken, maar ben wat voorzichtig hierin. Dus voer ik de nodige experimenten uit.

Bevindingen van vandaag:

- rsync onder macOS is een 15 jaar oude versie, samen met een belangrijk deel van het Unix basis-systeem. Ergens eigenlijk schandelijk. Veel opties ontbreken en er zitten ook bugs en rariteiten die al jaren geleden zijn opgelosst in overige Linux en Unix versies. Niet onder macOS. Waar rsync inmiddels met UTF normalisatie overweg kan middels een parameter, zitten we onder macOS nog met een archaische versie 2.6.x ... Topper ...

- op externe schijven, bijvoorbeeld exfat schijven, schrijft macOS ongevraagd allerlei metadata weg (.DS_Store bestanden bijvoorbeeld). Heel leuk, maar een ramp als je de schijf weer in andere apparaten stop. Een leuke test is bijvoorbeeld oudere Mercedes auto's met een SD-Card reader, die kunnen niet echt overweg met bestanden met enkel een extensie en daarmee is de kaart onleesbaar. Natuurlijk kan ik een eenvoudige "find /Volumes/MuziekvoorindeAuto -type f -exec rm -rf {} \;" ingeven, maar kop op ... Geef ons de optie. Wat blijkt, die is er ...

... in de terminal ... Ja ho eens, is het een GUI of een CLI-based OS?

- Zoals geschreven heb ik verschillende tools gebruikt. Heb nu ook in plaats van NTFS het ExFAT bestandssysteem gebruikt (op de PC alles overgezet van NTFS naar een verse ExFAT schijf). Maar de problemen die blijven. Het lijkt er echt op dat de UTF coderingen niet overeenkomen. MAAR ...

... het verschil: ik sleep de map naar de destkop via de finder en ik krijg geen enkele foutmelding. Ga ik "onder water" en doe ik een vergelijking op bestandsniveau en op inhoud dan ontbreken er allerlei bestanden. Dat is dramatisch!

rsync -azh --dry-run --delete-after /Volumes/Source /Destination
file has vanished: "/Destination/Dossier Benelux/Financie?\#210n"
file has vanished: "/Destination/Teståáaąço"

rsync warning: some files vanished before they could be transferred (code 24) at /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-54.120.1/rsync/main.c(996) [sender=2.6.9]

En dat is in zijn geheel niet gemeld door de finder!

Werk je met FreeFileSync, dan wordt er tijdens het synchroniseren allerlei meldingen gegenereerd dat er geen toegang gekregen kan worden tot de bestanden. Draai ik HETZELFDE programma (FreeFileSync) onder Linux: bam ... probleemloos. Ook de checksums (gegenereerd op Windows met de bronbestanden) kloppen. Draai ik rsync onder Linux: boem ... foutloos. Ook weer checksums die kloppen en alle bestanden die mee zijn gegaan.

Onder macOS mis ik een deel van de bestanden en kreeg ik daar 0,0 terugkoppeling op. Een soorgelijk probleem jaren geleden gehad met zakelijke data van een project, andere context, andere OS versie maar wel synchronisatie issues op het netwerk. Probleem was toen (naar het bleek) de vertaalslag die gemaakt werd door (toen) MacOS X van de bestandsnamen.

Heb zojuist tests afgerond met rClone via het netwerk. Hier had rClone beduidend wat werk in het overzetten van Onedrive en Amazon bestanden van de cloud. Ook hier weer missing files ... Met wat aanpassingen bleek ook hier weer het probleem te zitten in het niet kunnen wegschrijven van bepaalde bestanden op het bestandssysteem.

Heb zojuist een soortgelijke test uitgevoerd met HFS+ (oude schijf met moeilijke data van een MacOS 10.7 omgeving) met ... vergelijkbare problemen.

Dus ... met alle respect, zonder woede, emotie of andersoortige: wat moet ik dan schrijven?

Dat alles perfect op orde is, dat ik geen problemen heb mogen ervaren en dat alles in dit geval wat geschreven is de reinste ######## is?

De reden van mijn experiment is ook simpel:

Ik heb enige tijd terug een Mac Mini 2018 gekregen. Althans niet cadeau, omdat ten gevolge van Covid-19 een debiteur zijn schuld niet meer kon betalen. Dikke schade, ellende, maar ik heb een Mac Mini 2018 gekregen uit zijn inboedel. Ik zou er nog 50 moeten krijgen om de schade enigszins te dekken, maar goed. Ik ben niet boos, de man kan er zelf ook weinig aan doen. Gevolgschade van de crisis. Wel met zware gevolgen voor mij.

Hoe dan ook, ik heb oprecht de ambitie om 'weder te keren' naar het Apple platform. En om de kennis weer op te rakelen en eens een tijdje de zaken weer te ervaren. Ik heb 'Mojave' en 'Catalina' gemist en kort op 'High Sierra' gewerkt. Voor die tijd alles gehad sinds MacOS 6.0.8 ...

Ik heb geen hekel aan Apple, maar wel aan matige kwaliteit en als dingen niet naar behoren werken. Ik zoek nog steeds naar een OPLOSSING. Ben alsmaar dieper aan het graven, maar geen oplossing nog gevonden anders dan het volgende:

Optie 1

- Kopie van de data via finder. Validatie uitvoeren op bestanden die wel over zijn gegaan.
- rClone gebruiken voor de missende data om zo data kosten te verminderen. We hebben het hier over paar honder gigabyte om te beginnen. Uiteindelijk blijkt 2.4GB aan data 'zoek te zijn'
- rClone herhaald uitvoeren met de nodige parameters omdat anders de transfer mislukt.
- Als alles klaar is handmatig een checksum valideren op verschillen en missing files.

Resultaat: gelukt met kanttekening

Optie 2:

- Zet alles over naar Cloud
- Gebruik een tool waar UTF-8 normalisatie ingebakken zit. Afhandeling van netwerk is onder macOS overigens (qua naamgeving) anders (in mijn test) dan met bestandssystemen. Onedrive en Google lijkt hierin te kunnen voorzien. Maar dan moet de data dus wel op de cloud staan.

Resultaat: gelukt, maar ook hier herhaalde pogingen nodig

Optie 3:

- Gebruik Apple's HFS+ of APFS drivers van Paragon of Apple zelf (bootcamp) in Windows en zet onder Windows alle data weg naar HFS+ (of APFS).

Ironisch genoeg werkt dat in dit geval. Maar da wil ik niet. Ook in de toekomst wil ik - als ik weer terug zou keren voor prive naar Apple - dat macOS dit gewoon afhandeld.

En hier wringt te schoen. Ik ben bedreven genoeg om work-arrounds te vinden, maar ik wil het liefst een oplossing voor een (verhoudingsgewijs) basaal onderdeel van het OS: bestandsbeheer. Ook wil ik terugkoppeling krijgen als iets wordt genegeerd tijdens het overzetten.

en mijn stelling over onbetrouwbaar ... Wel, ik heb drie dagen gevochten om een WERKENDE backup te kunnen maken onder Catalina en Big Sur middels de prompt. Probleem zat hem in schaduwkopieen (snapshots) en de matig werkende ASR, HDIUTIL en DISKUTIL.

Er werd aangegeven een volwaardige kopie te hebben weggeschreven. Maar dan een herstel geprobeerd uit te voeren: talloze keren mislukt in verschillende testscenario's.

Dat noem ik onbetrouwbaar.

Dan maar Timemachine geprobeerd ... En daar stop ik even omdat daar mijn bloeddruk van stijgt ...

... Apple onwaardig ...

Ik ben erg te spreken over de sprong naar APFS, maar veel lijkt gewoon 'nog niet af' en dat vind ik voor een premium merk wel kwalijk. Immers, ik gaf altijd af op MSDOS-loosers en Windows-gekkies dat ik een Apple gebruikte omdat ik thuis geen systeembeheerder wilde spelen.

Een backup is een wezenlijk onderdeel van een OS. Dus een slecht, matig of ondoorzichtig werkend mechanisme is een major fault. Solide gegevensoverdracht (en dus onderdeel van beheer) is dat ook.

Moet ik nu bij elke grote migratie alles handmatig valideren? Is dat nu macOS anno 2021?

Ik weiger dat te geloven. Verdere hulp is natuurlijk welkom, daar ik geloof dat ik niet alles weet en mogelijk gewoon iets over het hoofd zie.

Verdere (constructieve) input is dus welkom. Kritiek is niet omdat ik een hekel heb aan Apple of Apple gebruikers. macOS schuurt in vele opzichten dicht tegen de perfectie aan. Knulligheden als dit vind ik kwalijk. Als Mint Linux, OpenSUSE en zelfs Windows 10 versie 20H2 het kan. Waarom kan macOS het niet?

De GUI is praktisch perfect. Maar onder de motorkop is toch het nodige aan werk blijven liggen of matig uitgevoerd.

Ik zou gewoon zoveel meer met plezier richting de Linux en Windows mensen willen roepen: zie je wel ... Appeltje Eitje dat synchroniseren met DAS en Cloud ... Zelfs het antieke NTFS was geen probleem.

Zo, genoeg sentiment. Nu eens spelen met Mail kijken wat er allemaal veranderd is sinds High Sierra. Heb meerdere accounts te koppelen aan de Mac, dus kijken hoe dat gaat.

Onverminderde groet!
antw: Bestanden kopiëren en synchroniseren van/naar Mac
19 januari 2021 - 20:05    reactie #9
geplaatst door: Kapotlood
Ik hoop dat iemand je hier verder mee kan helpen Doctor_Apple, de posts zijn zo lang dat er voor mij niet echt een doorkomen aan is :)
antw: Bestanden kopiëren en synchroniseren van/naar Mac
19 januari 2021 - 20:09    reactie #10
geplaatst door: boiing
Onverminderde groet inderdaad! Een normaal gesprek over waar het nou écht om gaat is onmogelijk met jou doctor_apple. Je quote mijn antwoord maar beantwoordt niet mijn vraag, laat staan dat je er inhoudelijk en feitelijk op ingaat.

Klopt, voor wat betreft NTFS en Exfat, niet voor Ext4.
ext4 doet geen bestands-foutcorrectie, wel metadata. Net als APFS.
antw: Bestanden kopiëren en synchroniseren van/naar Mac
19 januari 2021 - 23:01    reactie #11
geplaatst door: MacFrankie
@doctor_apple
TL;DR
Op mijn werk heb ik al Windows, thuis wil ik geen systeembeheerder meer zijn!
antw: Bestanden kopiëren en synchroniseren van/naar Mac
20 januari 2021 - 10:20    reactie #12
geplaatst door: MacWim
 :reading: :wacko:
Amper te volgen. Toch leer ik hier wat van - juist door het níet allemaal te lezen. Namelijk: kies bij bestandsnamen voor simpel.
Ik prijs me nu gelukkig dat ik al lang geleden bij bestandsnamen 'correct en compleet' durfde los te laten en koos voor kort en kaal. Dus geen umlauts en andere nauwkeurigheden en dingen als puntkomma's en slashes.
Telkens is er weer de neiging om het toch correct en compleet te doen, maar dank je @docter_apple  :worship: – doe ik toch maar niet.
Mac mini M1, 16 GB 1TB | MBA 6.2 | iPhone 12 mini | iPad Pro 11" 2021 | iPod touch 2009 | Apple TV 3
Bouw websites; webteksten; beeldbewerking met Pixelmator Pro. interlijn.nl
antw: Bestanden kopiëren en synchroniseren van/naar Mac
20 januari 2021 - 10:35    reactie #13
geplaatst door: MacFrankie
Inderdaad, de KISS methode. Voorkomt een hoop (onnodige) problemen.
Op mijn werk heb ik al Windows, thuis wil ik geen systeembeheerder meer zijn!
antw: Bestanden kopiëren en synchroniseren van/naar Mac
20 januari 2021 - 12:20    reactie #14
geplaatst door: jaco123
@dr_apple: Ik ben altijd blij als ik je posts lees. Eindelijk iemand die doorzoekt en doorgraaft tot hij het begrijpt.

Ik ben het ook absoluut eens dat:
- Apple enorm heeft geblunderd door bij APFS data-integriteit niet mee te nemen (zeker na hun avontuur met ZFS wisten ze donders goed dat dat prima kan werken).
- Bestandsnamen gewoon moeten werken. Het is niet de taak van een filesysteem om daar stiekem conversies op te doen. Als er bepaalde constructies niet werken, geef dan een foutmelding, maar ga niet aan de haal met de door de gebruiker gekozen namen!

(Ik sla mijn belangrijke data op, op een (zelfbouw) NAS met ZFS. Heerlijk die geruststelling dat je data nog precies zo is zoals hij was toen je hem er op zette. Maar heb wel af en toe gedoe met bestandsnamen met speciale karakters erin...)
antw: Bestanden kopiëren en synchroniseren van/naar Mac
20 januari 2021 - 12:28    reactie #15
geplaatst door: boiing
Doorzoeken en graven wordt altijd gewaardeerd. Ik zal alleen nooit m'n mond houden als er m.i. onzin wordt verkondigd. De eerdere conclusie van doctor_apple 'bestandsbeheer op macOS is gewoon niet betrouwbaar' en nu ook jouw uitspraak dat 'Apple enorm heeft geblunderd' zijn niet waar. Het is een keuze, waar redenen voor zijn (onderzoek dat maar eens). Windows en de meeste Linux systemen werken ook zonder, het heeft dus niets met Apple te maken. Alleen ZFS en Btrfs doen aan checksum controle op bestandsniveau en die zijn vooralsnog nog lang niet mainstream.

Je mag natuurlijk best vinden dat Apple voor ZFS had moeten gaan i.p.v. APFS. Ze zullen daar hun redenen voor hebben gehad en daar lang en goed over nagedacht hebben. Performance en betrouwbaarheid zullen hoog op de eisenlijst hebben gestaan, maar checksum controle op zich is niet alleen zaligmakend. Het zorgt bovendien alleen voor detectie, geen reparatie.

Citaat
Bit rot just doesn’t work that way. I am absolutely sick and tired of people in forums hailing ZFS (and sometimes btrfs which shares similar “advanced” features) as some sort of magical way to make all your data inconveniences go away. If you were to read the ravings of ZFS fanboys, you’d come away thinking that the only thing ZFS won’t do is install kitchen cabinets for you and that RAID-Z is the Holy Grail of ways to organize files on a pile of spinning rust platters. In reality, the way that ZFS is spoken of by the common Unix-like OS user shows a gross lack of understanding of how things really work under the hood.

Citaat
A certain category of people are terrified of the techno-bogeyman named “bit rot.” These people think that a movie file not playing back or a picture getting mangled is caused by data on hard drives “rotting” over time without any warning. The magical remedy they use to combat this today is the holy CRC, or “cyclic redundancy check.” It’s a certain family of hash algorithms that produce a magic number that will always be the same if the data used to generate it is the same every time.

This is, by far, the number one pain in the ass statement out of the classic ZFS fanboy’s mouth and is the basis for most of the assertions that ZFS “protects your data” or “guards against bit rot” or other similar claims. While it is true that keeping a hash of a chunk of data will tell you if that data is damaged or not, the filesystem CRCs are an unnecessary and redundant waste of space and their usefulness is greatly over-exaggerated by hordes of ZFS fanatics.

https://www.jodybruchon.com/2017/03/07/zfs-wont-save-you-fancy-filesystem-fanatics-need-to-get-a-clue-about-bit-rot-and-raid-5/

Van mij wel een tl;dr over 'bit-rot', ik citeer bovenstaande link:

Hard drives already do this, the risks of loss are astronomically low, ZFS is useless for many common data loss scenarios, start backing your data up you lazy bastards, and RAID-5 is not as bad as you think.

Bewerkt: 20 januari 2021 - 16:33 door boiing
antw: Bestanden kopiëren en synchroniseren van/naar Mac
20 januari 2021 - 13:27    reactie #16
geplaatst door: Kapotlood
Doorgraven wordt inderdaad altijd gewaardeerd, ook van Doctor_apple uiteraard :)

Maar als je een probleem hebt en wilt uitleggen, hou 't een beetje overzichtelijk en kort. Een levensverhaal opschrijven en diverse zijwaartse sprongen maken met verschillende onderwerpen, en daar omheen nog allerlei code plakken maakt 't erg onoverzichtelijk en ondoorgrondbaar. Van wat ik uit z'n berichten kan halen bestaat z'n vraag (en diverse bevindingen) uit meerdere onderdelen en onderwerpen namelijk, en daar is bijna geen wijs uit te komen.

Als je de code deelt, waarom niet in een Text file via een linkje bijvoorbeeld? Of zeg kort en bondig wat je wilt: Ik wil bestandsdeling tussen een Mac, Linux en Windows machine, en niet via een NAS maar via X. En zet daaronder even simpel en kort wat je al geprobeerd hebt. Dat maakt 't voor iedereen makkelijk te begrijpen, en dat levert denk ik ook veel betere antwoorden op :)
antw: Bestanden kopiëren en synchroniseren van/naar Mac
20 januari 2021 - 15:04    reactie #17
geplaatst door: Flix
Wel grappig (zonder dat ik al zijn voorgaande reacties diepgaand heb bestudeerd) dat doctor_apple een underscore in zijn nick gebruikt, wat zijn (digitale) oorsprong kent in de beperking van het FAT file systeem, waar spaties in bestandsnamen niet begrepen worden.

Het woord 'haat' zal ik niet vaak gebruiken, maar nu wel: ik haat underscores! :cool:
Het is visueel zo'n akelig ding, zo niksig, zo lelijk! Gebruik dan niks (zet de woorden aan elkaar), of een hyphen (streepje), of een spatie (wat tegenwoordig zelden meer een probleem is).
Maar god verhoede me: nóóit een underscore!

🤪


Oké, ik ben ook een beetje gek...


Bewerkt: 20 januari 2021 - 16:00 door Flix
antw: Bestanden kopiëren en synchroniseren van/naar Mac
20 januari 2021 - 16:53    reactie #18
geplaatst door: jaco123
Doorzoeken en graven wordt altijd gewaardeerd. Ik zal alleen nooit m'n mond houden als er m.i. onzin wordt verkondigd. De eerdere conclusie van doctor_apple 'bestandsbeheer op macOS is gewoon niet betrouwbaar' en nu ook jouw uitspraak dat 'Apple enorm heeft geblunderd' zijn niet waar. Het is een keuze, waar redenen voor zijn (onderzoek dat maar eens). Windows en de meeste Linux systemen werken ook zonder, het heeft dus niets met Apple te maken. Alleen ZFS en Btrfs doen aan checksum controle op bestandsniveau en die zijn vooralsnog nog lang niet mainstream.
Tja, of het nou "enorm geblunderd" is of gewoon een "gemiste kans", dat is subjectief en zal iedereen anders beleven.
Feit blijft dat Apple APFS compleet van scratch af aan heeft opgebouwd. Je zou verwachten dat je dan alle moderne en state-of-the-art features van andere filesystems onderzoekt en de nuttige overneemt.
Apple is in het verleden altijd heel ver gegaan in betrouwbaarheid van data (ik kan me nog herinneren dat ik mijn Xserves harde schijven had waarin de harde schijf zelfs Apple-specifieke firmware had om de betrouwbaarheid te verhogen...). Ook Mac OSX Server performde knap beroerd qua fgilesystem I/O met name voor databases. Linux performde destijds veel beter. Apple legde dat uit dat ze de kans op datacorruptie geminimaliseerd hadden en dat dat nou eenmaal niet sneller kan.

Ik snap dan ook echt niet waarom Apple data-integriteit op filesystem niveau niet geïmplementeerd heeft. Vind Apple data-integriteit ineens niet meer zo belangrijk?

Ok, als ze APFS ook op low-end hardware (Apple Watches)willen gebruiken, dan hadden ze het een configureerbare feature kunnen maken. En de argumenten van destijds "Apple gebruikt alleen A-klasse hardware, waardoor de feature minder nuttig is" vond ik toen al flauwekul: wat doe je dan met externe schijven of systemen met een half losse sata-kabel? Is data-integriteit dan ineens niet belangrijk? Had je maar een duurdere schijf moeten kopen of zo? Je wil gewoon iets betrouwbaars hebben. Block-level checksums in je filesysteem kosten geen significante performance en is dus voor mij van de categorie "no-brainer, gewoon implementeren".  Het mooie van ZFS vind ik dat de checksum van een block niet IN het block zelf staat. Immers, als er corruptie in een block ontstaat is het erg fijn dat je dat kunt detecteren met informatie die elders opgeslagen is.

Feit blijft dat als je in de Finder een map met bestanden van A naar B kopieert dat de Finder AANNEEMT dat het goed is gegaan als er geen error van de onderliggende devices komt. Ik houd niet van aannames.
doctor_apple gaat nog iets verder, die doet de controle zelf middels vooraf en achteraf berekenen van checksums over alle bestanden. Dat doe ik alleen als ik verschillen vermoed, maar als er ergens in de Finder-voorkeuren en vinkje "altijd verifiëren van kopieeracties" zou bestaan dan zou IK dat altijd aanzetten. Anderen die de hardware vertrouwen kunnen dat dan naar wens uitzetten. Maar goed, zo'n vinkje is er niet en komt er niet, dat zou natuurlijk niet des Apples zijn: dat moet gewoon werken en gebruikers moet je niet vermoeien met keuzes die ze niet hoeven te begrijpen. Daarom vind ik het verbazingwekkend (om niet te zeggen een enorme blunder...) dat Apple niet default kiest voor dataintegriteit.

Citaat
Je mag natuurlijk best vinden dat Apple voor ZFS had moeten gaan i.p.v. APFS. Ze zullen daar hun redenen voor hebben gehad en daar lang en goed over nagedacht hebben.
Dat was -helaas- een juridisch dingetje met licenties. Het zat al in de beta's en werkte in principe, maar is er toen weer uitgehaald. Pas jaren later kwam APFS als vervanger van HFS+. Je ziet in veel dingen van APFS (bijvoorbeeld het huidige gebruik van APFS-containers) dat Apple zich wel behoorlijk door ZFS heeft laten inspireren.

Citaat
https://www.jodybruchon.com/2017/03/07/zfs-wont-save-you-fancy-filesystem-fanatics-need-to-get-a-clue-about-bit-rot-and-raid-5/

Ik heb je hele link gelezen. Het was niet mijn bedoeling om in een religieus ZFS vs RAID-5 discussie te belanden.
Voordat ik op ZFS overgestapt ben heb ik de werking van ZFS in veel detail bestudeerd. Als IT-er kan ik alleen maar zeggen "dat zit mooi in elkaar" Ik vind data integriteit belangrijk en ZFS levert dat.
Ik las dat doctor_apple wel degelijk voor hem belangrijke bestanden kwijtgeraakt is, dus ik kan dat begrijpen.
Ook ik heb in mijn studententijd wel eens wat dataverlies gehad waar ik enorm van baalde. Sindsdien is data-integriteit belangrijk voor me.

De aloude wijsheid geldt nog steeds:
Mensen die niet backuppen hebben nog nooit een backup nodig gehad.
Een variatie daarop is:
Mensen die data integriteit niet belangrijk vinden hebben nog nooit verminkte belangrijke data gehad.....
antw: Bestanden kopiëren en synchroniseren van/naar Mac
20 januari 2021 - 16:56    reactie #19
geplaatst door: jaco123
Doorgraven wordt inderdaad altijd gewaardeerd, ook van Doctor_apple uiteraard :)

Maar als je een probleem hebt en wilt uitleggen, hou 't een beetje overzichtelijk en kort. Een levensverhaal opschrijven en diverse zijwaartse sprongen maken met verschillende onderwerpen, en daar omheen nog allerlei code plakken maakt 't erg onoverzichtelijk en ondoorgrondbaar. Van wat ik uit z'n berichten kan halen bestaat z'n vraag (en diverse bevindingen) uit meerdere onderdelen en onderwerpen namelijk, en daar is bijna geen wijs uit te komen.

Als je de code deelt, waarom niet in een Text file via een linkje bijvoorbeeld? Of zeg kort en bondig wat je wilt: Ik wil bestandsdeling tussen een Mac, Linux en Windows machine, en niet via een NAS maar via X. En zet daaronder even simpel en kort wat je al geprobeerd hebt. Dat maakt 't voor iedereen makkelijk te begrijpen, en dat levert denk ik ook veel betere antwoorden op :)

Ik focus altijd op inhoud, en als de tekst moeilijk leesbaar is, dan houdt me dat niet tegen als de inhoud me fascineert.
Maar je hebt gelijk: Compacte heldere tekst-structuur en leesbaarheid helpen wel als je een goede discussie wil voeren.
antw: Bestanden kopiëren en synchroniseren van/naar Mac
20 januari 2021 - 17:03    reactie #20
geplaatst door: boiing
Een mooie duidelijke reactie jaco123 :thumbs-up:. 'Blunder' blijf ik onzin vinden, 'gemiste kans' is een mening zoals ik al zei. Ik begrijp je punt ook wel, het lijkt een mooie feature van ZFS, die data-integriteit. Maar de kern staat wat mij betreft toch in de tl;dr die ik gaf. De kans is astronomisch klein omdat de opslagmedia zelf aan error-correctie doen (volgens quotes van Apple engineers was dit ook de belangrijkste reden om het niet te gebruiken). ZFS voorkomt op zichzelf geen dataverlies of bit-rot, het detecteert alleen. En er zijn ook nadelen.

Belangrijker: volgens mij staan mede dankzij jouw laatste reactie alle argumenten voor en tegen nu in dit draadje en kan iedereen zijn eigen mening hierover vormen. Voor wie het heeft volgehouden tot hier althans :biggrin:.
antw: Bestanden kopiëren en synchroniseren van/naar Mac
20 januari 2021 - 21:31    reactie #21
geplaatst door: jaco123
Een mooie duidelijke reactie jaco123 :thumbs-up:. 'Blunder' blijf ik onzin vinden, 'gemiste kans' is een mening zoals ik al zei. Ik begrijp je punt ook wel, het lijkt een mooie feature van ZFS, die data-integriteit. Maar de kern staat wat mij betreft toch in de tl;dr die ik gaf. De kans is astronomisch klein omdat de opslagmedia zelf aan error-correctie doen (volgens quotes van Apple engineers was dit ook de belangrijkste reden om het niet te gebruiken). ZFS voorkomt op zichzelf geen dataverlies of bit-rot, het detecteert alleen. En er zijn ook nadelen.

Tja, ook al is de kans klein, dat betekent toch niet dat je geen maatregelen hoeft te nemen? Ik rijd al 20 jaar rond in auto's met airbags, maar nog nooit nodig gehad.
Andere lastige ding van data-integriteit is dat je corrupte bestanden helemaal niet zo makkelijk opmerkt, zeker in een archief. Hoeveel bestanden (foto's, video's, documenten etc) heb je in je archief die je jaren achter elkaar niet opent?

Ik vind het dan prettig dat ZFS zelf alles kan controleren en desnoods corrigeren. Je weet waar je aan toe bent en als het niet te herstellen is dan geeft hij aan welke bestanden een fout hebben.

Of ZFS kan corrigeren hangt uiteraard af van de mate van redundantie. Als je een mirror of zraid hebt, dan is er redundantie, maar zelfs op een enkele schijf kun je instellen dat je alle data dubbel (of drievoudig of nog meer...) wegschrijft.
Van mijn NAS maak ik via zfs send/receive backups op externe/offline schijven. Daar gebruik ik altijd copies=2, kost uiteraard 2 keer zo veel ruimte, maar er is wel dataredundantie.

Is ZFS perfect? Nee hoor, afgelopen kerstvakantie behoorlijk zitten puzzelen en zuchten. Mijn ZFS-pool stamt al uit 2012, ooit begonnen met 3x3TB-schijven en door de jaren heen gegroeid met een paar keer grotere schijven (sinds de kerstvakantie 3x12TB ). Maar als ZFS volloopt gaat de vrije ruimte nogal fragmenteren. Dat kost performance (zeker met TimeMachine met die 10-duizenden 8MB-files in een sparsebundle). Er bestaat geen defrag-tool en het komt ook niet vanzelf goed zodra er weer ruimte is. Officiële "oplossing" is om de hele pool te wissen, weer opnieuw aan te maken en je backup terug te zetten. Dat kostte me teveel downtime. Anyway, na een hoop gepuzzel en veel heen en weer kopiëren naar externe schijven, bron wissen en dan terugzetten is het weer aardig op orde. Erg geruststellend dat je er dan op kunt vertrouwen dat die kopieer-acties correct zijn.

Citaat
Belangrijker: volgens mij staan mede dankzij jouw laatste reactie alle argumenten voor en tegen nu in dit draadje en kan iedereen zijn eigen mening hierover vormen. Voor wie het heeft volgehouden tot hier althans :biggrin:.

Daar doen we het voor. Als er mensen wat van op steken dan is het de moeite waard om het op te schrijven.
Respect voor de volhouders!  :worship:
antw: Bestanden kopiëren en synchroniseren van/naar Mac
20 januari 2021 - 22:12    reactie #22
geplaatst door: HEXDIY
Ik lees en leer hier elke dag mee, hoor!
Bedankt voor de uitgebreide posts allemaal.
Heel wat anders dan twitterachtige one-liners op andere fora!
If it ain't broke, don't fix it! Recycle the planet, we're gonna need it! Think different, think twice, Apple!
M1 is a success! Please do not forget Mac OS.
antw: Bestanden kopiëren en synchroniseren van/naar Mac
21 januari 2021 - 09:05    reactie #23
geplaatst door: MacFrankie
Is de TS inmiddels afgehaakt?

...
Overigens een kanttekening: rclone geprobeerd met zowel Google Drive en one drive en tijdens het synchroniseren (na het valideren middels een controlelijst (checksums)) blijken diverse bestanden te worden genegeerd bij het synchroniseren. Zoals je waarschijnlijk aan je water kunt voelen: bestanden met meerdere leestekens of bepaalde combinaties (waaronder natuurlijk de dubbele punt).

Wie kan hiermee helpen?
Ik, met een (open deur) tip: Keep It Simple S...!

Bestandsnamen zijn slechts bestandsnamen. Je ziet ze niet als je een bestand print. Het zijn geen zinnen, ze moeten geen leestekens bevatten, ze hoeven zelfs niet correct te zijn gespeld, want de spellingscontrole negeert het.

Beperk de karakters die je voor je bestanden gebruikt tot de karakterset bestaande uit 26 hoofdletters, 26 kleine letters, 10 cijfers, het underscore teken, misschien het minteken, en de punt.

DOS en Windows gebruiken de dubbele punt om een drive (1 letter) of een device (printer, seriële poort) aan te duiden.

Unix en afgeleiden gebruiken vertical bar, groter dan en kleiner dan voor redirects.

Komma's en puntkomma's worden als scheidingsteken gebruikt.

Aanhalingstekens worden als begrenzingen voor strings (waaronder ook bestandsnamen) gebruikt.

Tekens die niet tot de ASCII karakterset behoren zitten in een bepaalde karakterset en hebben een speciale codering. Karakterset en codering kunnen per filesystem / OS verschillen.
Op mijn werk heb ik al Windows, thuis wil ik geen systeembeheerder meer zijn!
antw: Bestanden kopiëren en synchroniseren van/naar Mac
21 januari 2021 - 13:41    reactie #24
geplaatst door: doctor_apple
Een aantal puntjes

  • Het had absoluut compacter gekunt ...
  • Had mogelijk niet de ongefragmenteerde stroom aan gedachten moeten optekenen
  • Anderzijds: er is nog steeds keurig gediscusseerd voors en tegens gegeven
  • Dit is een verademing ... Zeker in het tijdperk van instagram, snapchat, twitter en alles dat vluchtig is

Echter ...

Dit allemaal opgetekend hebbende is er in ieder geval wat naslagwerk hoe checksums te genereren en wat er allemaal mis kan gaan.

Na enig zoeken kwam ik tot de conclussie dat dit probleem al eerder voorkwam in macOS 10.14. Daarover was ook een klacht geplaatst op een Apple Forum:

Apple Supportforum

Het is me gelukt om de data 100% over te zetten naar macOS, maar daarbij moest ik echt gebruiken maken van een combinatie van technieken. Uiteindelijk heb ik de namen middels de nodige scripts, zoveel mogelijk "gestript" naar eenvoudige tekens. Maar ... Ikzelf spreek, lees en schrijf ook nog in andere talen dan het Nederlands waar je soms gewoon niet om die andere leestekens heen kunt.

Komende dagen twee experimenten: transfer middels archief-bestand (tape archive - TAR) en de werking van APFS/HFS+ (oftewel macOS) naar NTFS en ExFAT.

Zodra ik meer weet zal ik het draadje opzoeken en hier mijn bevindingen vermelden. Hopenlijk dan met een oplossing.

Ik zal pogen iets meer zorg te dragen voor structuur binnen mijn posts, alsook op diens lengte. Maar verval niet tot verbaal geweld als ik een vlaag van verstandsverbijstering toch weer verval in oude (slechte) gewoontes.

Groet!

Doctor :apple:


Post Scriptum
Ehm, ja ... veel operating systemen mogen 'knuffelen'. Daarbij hoorden tevens CP/M, Olivetti PC/OS, MS-DOS, Apple DOS, Atari TOS en vele andere archaische systemen ... met ... *kuch* ... opa verteld: beperkingen in de bestandsnamen. En inderdaad ... betrapt ... de naam is een dikke knipoog naar besturingssystemen uit mijn jonge jaren.