Vanaf mijn macbook heb ik een USB stick geformatteerd in MS DOS FAT. Op de geformatteerde stick heb ik vanaf mijn macbook muziek gekopieerd.

De eerste keer werkte de USB stick prima in mijn auto.

Daarna nog meer muziek bestanden op de USB stick gezet. Echter konden deze nieuwe files niet afgespeeld worden in mijn auto. Kreeg de melding dat de bestandstype niet werd ondersteund. bij controle op mijn macbook kreeg ik een lege map te zien met vreemde rode letters.

Daarop de USB stick opnieuw MS DOS FAT geformatteerd en alle muziek inclusief de nieuwe er weer opgezet. Helaas kan mijn auto nu helemaal niets meer aflezen van de USB stick en krijg ik de melding dat het bestandstype niet wordt ondersteund.

Op mijn werk de USB stick in de Windows laptop gedaan en een muziek bestand geopend, krijg ik bij meerdere muziekbestanden de melding dat het bestand beschadigd is en niet geopend kan worden.

Mijn andere externe harde schijf welke speciaal voor de Mac is, wordt nu ook niet meer herkend. Terwijl deze het altijd heeft gedaan. Wordt wel herkend bij schijfhulpprogramma's.

Heeft iemand een idee wat er mis kan zijn? Hoe krijg ik de USB stick weer werkzaam voor in de auto en hoe kan ik mijn externe harde schijf weer zichtbaar maken?
En hoe kan ik muziek op de USB stick zetten zonder hem iedere keer te moeten formatteren?

Ik heb overigens ook bij verborgen bestanden gekeken en deze verwijderd, ook de bibliotheek leeggemaakt. Daarnaast lukte het mij ook niet om de USB stick te verwijderen, dit heb ik gedaan nadat ik de laptop uit heb gezet.

Ik hoop dat iemand mij kan helpen.

Heb je je USB stick fysiek verwijderd zonder 'm netjes in OS X te verwijderen? Daardoor kunnen bestanden beschadigd raken. Dit hoef je overigens niet zelf te hebben gedaan, het kan ook door een brakke USB hub gebeurd zijn. Je USB stick opnieuw formatteren en de muziek er opnieuw opzetten is dan de oplossing.

Eén van de onhebbelijkheden van een Mac is dat hij overal verborgen bestanden neerzet. Daar heb je normaal geen last van, maar soms wel. Vooral autoradio's hebben er last van (mijn Volvo autoradio kon er niet tegen). Maar gelukkig is daar een goede oplossing voor: Eject for Windows.

Download en installeer dit programmaatje, en zet het in je Dock. In plaats van je USB stick naar de prullenbak te slepen, sleep je 'm naar je Eject for Windows icoontje. De overbodige verborgen bestanden worden gewist, waardoor je autoradio er geen last meer van heeft.

Succes!

Ik ga het vanavond meteen even uitproberen. Ik laat het even weten als dit de oplossingen zijn!

daarom heeft iemand hier een klein programmatje voor gemaakt: Eject for Windows.
hiermee worden alle "overbodige" bestandjes verwijderd.

http://www011.upp.so-net.ne.jp/decafish/EjectForWindows/EjectForWindowsE.html

Even een update van mijn probleem die nu opgelost is.

Ik heb het programma Eject for Windows geïnstalleerd op mijn MacBook.

Ik heb de USB Stick eerst ex fat en daarna fat geformateerd. Alle muziek er weer opgezet en hem afgesloten met Eject for Windows. Dit laatste lukte niet en ik kreeg de melding dat de USB stick nog in gebruik was. Laptop afgesloten en de USB stick eruit gehaald. Vervolgens de USB stick meegenomen naar de auto en de helft van de muziek ging goed en de andere helft waren de mapjes niet bruikbaar...

Dus weer verder gezocht...

Ook geprobeerd ondertussen het probleem met mijn externe harde schijf (niet meer herkend) op te lossen. Dit heb ik als volgt opgelost:

- Malwarebytes anti-malware mijn laptop laten scannen (harde schijf was aangesloten).
- Malware gevonden en verwijderd.
- Laptop opnieuw opgestart.
- malwarebytes anti-malware nog een keer laten scannen. Laptop was schoon.
- home pagina van mijn safari veranderd.
- zoekmachine van safari aangepast

En wala mijn externe harde schijf was weer zichtbaar. Overigens stond er op die externe harde schijf een vaag EXEC bestand waardoor hij dus niet meer herkend werd. Dit bleek dus malware te zijn die ik heb opgelopen door de externe harde schijf aan een smart tv te koppelen.

Dus weer verder met de USB Stick.

Weer opnieuw de USB stick ex FAT en FAT geformateerd.

Mapje voor mapje de muziek erop gezet en gecontroleerd of alles het deed.
De USB Stick was 16 gb groot en bij 12 GB zette hij wel de map en de bestanden erop maar de bestanden waren leeg... Alles van voor de 12 GB werkte goed.

Dus maar een nieuwe USB stick gekocht. Alle muziek daarop gezet en de USB stick verwijderd met Eject for Windows.

En nu werkt de USB Stick ook weer als een zonnetje!

Dank jullie wel allemaal voor de hulp en ik hoop dat andere ook nog iets aan mijn terugkoppeling hebben.

MacOS X gooit .DS_Store, .Trash, Spotlight en nog wat bestandjes op NTFS en (ex)Fat(32) bestandssystemen ...

Windows gooit er (in geval van grafische bestanden) maar al te graag iets en de trend van 'thumbs' en soms ook een prullenbak-map op genoemde bestandssystemen.

En ook Linux kent tegenwoordig (afhankelijk van je desktop omgeving) de nodige troep ...

Als je niet gehinderd bent door enige vorm van kennis van de prompt, command line, shell of hoe je de command line interface (cli) wilt noemen ... Kan het zijn dat je het niet (goed) werkt, je heil moet zoeken in tooltjes om het 'te fixen' of erger: een handmatige excercitie om de zaken 'te schonen'.

Wel is mijn ervaring dat van alle systemen Apple MacOS X het wel het meest bond maakt ...

Het kan namelijk gebeuren dat elk denkbaar (multimedia) bestand voorzien wordt van een ._<originele bestandsnaam> ...

Even de technische werking daargelaten ...

Heb je een externe schijf met 200'000 bestanden, dan kan het best zo zijn dat je er opeens (bijna) 400'000 hebt, waarvan de helft uit 'handigheidjes voor MacOS X' bestaat ...

Gelukkig is dat met een simpele regel vanuit de terminal te schonen, maar ja ... de meesten weten het niet.

Daarnaast willen diverse systemen ook nog eens een 'viewer' of 'hulpprogramma' wegschrijven naar een stick ... Soms zelfs ongevraagd ... Hoe dan ook: ergerlijk.

Ooit handmatig een upgrade cd gemaakt waar allemaal MacOS X hulpbestanden op kwamen ... Kan m'n gevloek nog goed heugen ... De CD kwam er niet meer uit, het apparaat hing in z'n firmware upgrade modus en het humeur vervlogen tot het absolute nulpunt ...

Uiteindelijk de CD eruit gekregen en na inspectie kwam zag ik (mede) de .DS_Store bestanden op de CD ....

Mogelijk dat in Windows 13 of MacOS 12.3 de problemen worden verholpen   ... Het probleem speelt namelijk al jaren en het wordt er niet beter op ...

Net zoals de ondersteuning van exFat (Windows, Mac en Linux) ik niet echt terugzie bij de diverse hardware. De meeste hardware zit nog op Fat32 ondersteuning ... Maar geen 64bits exFat.

Ach, ja er is wat te dromen (en te zeuren)  

Meeste auto's ondersteuning Fat32, weinigen exFat ...

Verder kennen veel auto's een maximum bestands/folder-diepte ... Voorbeeld:

Z:\MUSIC\EIGHTIES\LATE\JACKSON\MICHAEL\COMPL_ALBMS\HD_AUDIO\BAD\I-AM-BAD.AAC

De folder-diepte in dit voorbeeld: (8 'folder diep') zal niet door alle (generaties) entertainmentsystemen geladen worden.

Wilt u de bewuste regel ook plaatsen?
Hartelijk dank

Doctor Apple om 15:38, 5-02-2016
Heb je een externe schijf met 200'000 bestanden, dan kan het best zo zijn dat je er opeens (bijna) 400'000 hebt, waarvan de helft uit 'handigheidjes voor MacOS X' bestaat ...

Gelukkig is dat met een simpele regel vanuit de terminal te schonen, maar ja ... de meesten weten het niet.

corthom om 9:48, 6-02-2016
Wilt u de bewuste regel ook plaatsen?

Anders in de Mac App Store zoeken op "Ds Store Remover", deze doet hetzelfde.

corthom om 9:48, 6-02-2016
Doctor Apple u schrijft: Gelukkig is dat met een simpele regel vanuit de terminal te schonen, maar ja ... de meesten weten het niet.

Wilt u de bewuste regel ook plaatsen?
Hartelijk dank

Docter Apple zit nog diep gebogen over Gray's Anatomy...

Bron: http://osxdaily.com/2012/07/05/delete-all-ds-store-files-from-mac-os-x/

Only for the uncouth. Ofte: de grove borstel.

Ik ben dankbaar voor dit topic, want ik heb zo 1 Sony 2GB USB stickje waar ik zowat elke ADB Mentor lichtcomputer mee laat vastlopen...
Wellicht te wijten aan .DS Store files. We zullen zien.

Dikke pech dat blijkbaar non-apple file systemen zoals EXT4 en Fat daarop soms vast blijken te lopen...

Mount je een USB stikkie in je Mac, weet dan dat Spotlight die gaat indexeren en DS_Store metadata gaat schrijven. Normaalste zaak van de wereld blijkbaar. Dikke pech als sommige toestellen daar niet mee overweg kunnen.
@ Doctor Apple: enig commentaar op deze automatische proliferatie van files onder BSD Unix met een Appel smaak?

(Bewerkt door HEXDIY om 2:40, 8-02-2016)

Doctor Apple om 15:38, 5-02-2016
Helaas lijkt het een 'mode' om ('onzichtbare') bestanden op filesystems achter te laten. Ook al wil je enkel een externe USB (flash/ssd/hdd) enkel lezen ...

Wel is mijn ervaring dat van alle systemen Apple MacOS X het wel het meest bond maakt ...

Het kan namelijk gebeuren dat elk denkbaar (multimedia) bestand voorzien wordt van een ._<originele bestandsnaam> ...

Even de technische werking daargelaten ...

Heb je een externe schijf met 200'000 bestanden, dan kan het best zo zijn dat je er opeens (bijna) 400'000 hebt, waarvan de helft uit 'handigheidjes voor MacOS X' bestaat ...

Gelukkig is dat met een simpele regel vanuit de terminal te schonen, maar ja ... de meesten weten het niet.

Daarnaast willen diverse systemen ook nog eens een 'viewer' of 'hulpprogramma' wegschrijven naar een stick ... Soms zelfs ongevraagd ... Hoe dan ook: ergerlijk.

Ooit handmatig een upgrade cd gemaakt waar allemaal MacOS X hulpbestanden op kwamen ... Kan m'n gevloek nog goed heugen ... De CD kwam er niet meer uit, het apparaat hing in z'n firmware upgrade modus en het humeur vervlogen tot het absolute nulpunt ...

Uiteindelijk de CD eruit gekregen en na inspectie kwam zag ik (mede) de .DS_Store bestanden op de CD ....

Mogelijk dat in Windows 13 of MacOS 12.3 de problemen worden verholpen   ... Het probleem speelt namelijk al jaren en het wordt er niet beter op ...

Net zoals de ondersteuning van exFat (Windows, Mac en Linux) ik niet echt terugzie bij de diverse hardware. De meeste hardware zit nog op Fat32 ondersteuning ... Maar geen 64bits exFat.

Ach, ja er is wat te dromen (en te zeuren)  

En van recente auto's weet ik niets.

HEXDIY om 2:35, 8-02-2016


Gelukkig maar, anders weet Time Machine niet meer wat te backuppen op je lokale HDD. Die simpele regel staat anders in een andere post van me voor degenen die mordicus willen doorgaan.

??? Het gaat toch om de externe HDD/SSD/USB? wat heeft dat te maken met je lokale (interne) HDD?

Daarnaast willen diverse systemen ook nog eens een 'viewer' of 'hulpprogramma' wegschrijven naar een stick ... Soms zelfs ongevraagd ... Hoe dan ook: ergerlijk.
Interessant. Enig voorbeeld?

Jazeker, ik heb de ervaring met bijvoorbeeld de Sony Bravia 8000 en 9000- Android Smart TV's

Er worden heel veel waarheden aangehaald binnen dit draadje ... Al moet gezegd: .DS_Store bestanden worden soms 'krachten toegedicht' die zie gewoonweg niet beschikken.

.DS_Store bestanden zijn bestanden die primair door de Finder worden aangemaakt om allerlei metadata over de betreffende map op te slaan, later is daar bijgekomen dat de bestanden tevens Spotlight data kunnen bevatten.

Maak je een ZIP-bestand aan vanuit de Finder? Dan bevat deze de bestanden, met daarbij een mapje _MACOSX met bestanden voorafgegaan met een punt (.) underscore (_) gevolgd door de bestandsnamen die in het zitbestand zijn opgeslagen. Betrof het een map, dan zitten daar tevens .DS_Store bestanden in ...

Synchroniseer je een map via FTP? Dan is het niet onwaarschijnlijk dat (wederom) allerlei metadata, maar in ieder geval .DS_Store bestanden, tussen de bestanden hun weg vinden naar de FTP-server ...

Kopieer je naar een bestandssysteem dat niet meta-data van het HFS+ bestandssysteem begrijpt? Dan worden dus .DS_Store bestanden plus de individuele meta-bestanden (voorafgegaan met ._) gekopieerd worden NAAST de feitelijke bestanden.

In de Finder worden mappen en bestanden, voorafgegaan met een punt (.) niet getoond. Hetgeen betekend dat je op een externe FAT32/ExFAT/NTFS/EXT [2/3/4] of voor mijn part een ZFS partitie de bestanden vanuit de Finder nooit zullen opvallen, immers: ze zijn onzichtbaar.

Maar ... Linux, (andere) Unix, Windows, Embedded devices ... Die zullen ze meestal wel laten zien, daar bestandsnamen (beginnend met een punt) bij vele besturingssystemen niet de functie hebben van 'onzichtbaar bestand'.

Je kunt dit makkelijk testen:

Maak een mapje aan in de finder: 'TEST'
Maak een tekstbestandje aan en plaats dit in de map ...

Comprimeer de map vanuit de finder ...

Open een terminal en type:

Dus: unzip (spatie) (min) l (spatie)

En sleep het icon naar de finder en druk op de enter toets ...

Je krijgt dan iets in de trend van:

Dit fenomeen doet zich tevens voor op externe media zoals USB-Sticks, HDD's, Memory Cards, enzovoorts ...

Een veel voorkomend probleem daarbij is dat je zeer lange bestands- en map-namen kunt hanteren met belachelijke 'dieptes' in MacOS X ... Een erfenis uit het unix-domein. Echter, zelfs binnen MacOS X is er een grappige discrepantie tussen de wijze waarop de Finder bestandsnamen hanteert en hoe de 'onderlaag' (Darwin) dat doet ...

De verschillen moeten gezocht worden in de afhandeling van leestekens, accenten en niet-latijnse schrijftekens.

Windows kent overigens een soortgelijk verschil (of probleem   )

Ook dit kun je makkelijk testen: pak een ExFat schijf en kopieer (een deel?) van je iTunes bibliotheek. Moet er wel het nodige in staan (arabische tekens, chinese tekens, russische tekens of franse tekens bijvoorbeeld?) met daarbij een behoorlijke bibliotheek die de nodige diepte kent (en lange bestandsnamen) ...

Start Windows op en kopieer de iTunes map naar een andere (externe of interne) schijf en de kans is groot dat Windows begint te klagen over niet gevonden bestanden (te lange bestandsnamen) ... Niets is minder waar, Windows kan prima omgaan met lange bestandsnamen, maar de afhandeling van UTF8/16 verschilt tussen de besturingssystemen en zo ook de afhandeling van zogeheten escape characters ...

Open je een Command Line onder Windows en geef je dan een kopieer opdracht? Dan kopieert Windows vrolijk en probleemloos alle bestanden in alle mappen ...

Is dit dan een probleem zuiver van de 'buitenwereld'?

Neen, Apple is vaker gevraagd om de wijze waarop deze omgaat met zijn 'externe leefomgeving' als het gaat om opslag (lees: externe opslagmedia en server-opslag) onder handen te nemen en er netter mee om te gaan.

Volgens mij bestaat deze roep al sinds MacOS 10.3 of 10.4 ... We zitten bij 10.11 en er is nog immer geen verbetering.

Om een voorbeeld te geven: ik heb zonet één van mijn externe iTunes schijven gepakt en aan de Mac Mini gehangen ...

Het is een ExFat Schijf die normaliter enkel aan Windows hangt ...

Laten we eens kijken wat MacOS 10.11 er van maakt:

Héj, hier heb ik niet om gevraagd!

Windows plaats één map: System Volume Information ... Met daarin de volgende bestanden:

En een map die dient als ‘prullenbak’: $RECYCLE.BIN

Enkel bij het mounten (aankoppelen) heeft Apple het volgende aangemaakt:

De punt-underscore bestanden bevatten daarnaast ook nog ‘ACL’, ‘Categorie’ (kleurtjes) en ‘notitie’ data …

Pak een m4a/aac/mp3 bestandje, vraag de informatie op vanuit de finder (cmd-I) en schrijf wat als notitie … Geef het een kleurtje vanuit de finder en sleep vervolgens het bestand naar het externe volume.

Als je dan de terminal opent en de directory bekijkt dan verschijnt er plotseling naast het audio-bestand (in dit voorbeeld) een meta-bestand:

En stel je nu eens voor dat je alle bestanden ‘read only’ hebt gemaakt in je iTunes directory, of … dat er bepaalde rechten aan zijn gekoppeld … of … dat je ze allemaal een categorie hebt meegegeven.

In dat geval zal bij het kopiëren vanaf een HFS+ (MacOS X) bestandssysteem naar een NTFS/ExFat of ‘non Mac’ bestandssysteem elke map en elk bestand voorzien worden van een ‘zusterbestand’.

En bij een bibliotheek van enkele honderden gigabytes aan iTunes data … tikt dat erg hard aan.

Hoe kun je dit schonen? Om het proces enigszins duidelijk te maken splits ik het schoningsproces in enkele stappen.

Open de terminal en type:

Je kunt ook volstaan door

in te geven en dan het icoon van de betreffende map of schijf te slepen naar de terminal. In dat geval zal de terminal zelf de locatie invullen.

Hiermee ‘verander je van locatie’ waar (vervolg) opdrachten betrekking op hebben

Je kunt de locatie ‘checken’ door de volgende opdracht in te geven:

Je krijgt dan een terugkoppeling in de vorm van:

Vervolgens plak je de volgende regel:

Hiermee ontdoe ik de externe schijf van zowel ‘MacOS X’ metadata als ‘Windows’ metadata.

De volgende mappen worden verwijdert:

.Spotlight-V100
.Trashes
.com.apple.timemachine.donotpresent
.fseventsd
$RECYCLE.BIN
System Volume Information

De laatste twee mappen zijn van het Windows-platform. Bestaan deze mappen niet, dan zal de opdracht gewoon uitgevoerd worden en zullen de mappen worden genegeerd.

Vervolgens wil ik dat het systeem op zoek gaat naar de .DS_Store bestanden en metabestanden voorafgegaan door een punt-underscore en deze van de externe schijf verwijdert.

Dit kan even duren … MacOS X zal nu elke directory doorlopen om te kijken of er bestanden zijn die voldoen aan de opgegeven criteria. En … afhankelijk van het type medium, gebruikte interface, maar zelfs MacOS X versie, processor en geheugen kan dit redelijk snel gaan of het kan een kwartiertje duren.

Zodra de Klaar verschijnt kun je de terminal afsluiten (cmd-Q) en de schijf vanuit de Finder verwijderen.

Belangrijke kanttekening: ga nu niet de schijf vanuit de Finder bekijken. Op het moment dat je dit doet zal het hele verhaal van voren af aan beginnen en de schijf opnieuw geschoond moeten worden.

Systemen waarvan ik weet dat die moeite hebben de aanpak van Apple zijn de audio entertainment systemen, zoals gebruikt in recente Audi’s (zelf ervaring met een Q5) en het COMAND systeem van Mercedes-Benz (ervaring met een C- en S-klasse).

Hiermee heb ik in het verleden grote SD-kaartjes voorbereid voor het gebruik in de auto. Zeker daar waar de navigatie van de apparaten nogal 'rudimentair' te noemen is. Kan het helpen een eigen structuur aan te brengen.

Een iTunes map is niet per definitie overal geschikt voor ...