De eerste paar keer dat het gebeurde, dacht ik dat ik spoken zag. Of dat ik me we moest vergist hebben, zoiets kan toch niet.
Maar nu ben ik er honderd procent zeker van, ik heb het zien gebeuren voor mijn eigen ogen.
- Op computer één (een Mac) staan een resem files, ik wil ze op computer twee krijgen.
- Doe twee Finder-vensters open. Selecteer alle files in venster één, en command-sleep die naar venster twee, aan de andere kant van het netwerk.
- In het tweede venster verschijnen de filenamen in het grijs; één voor één verdwijnen de files in het eerste venster en worden de grijze namen in het andere venster zwart: de files worden voor zover het er voor het blote oog uitziet inderdaad één voor één gemoved naar de andere computer.
- Er loopt iets mis, om de één of andere reden (een file blijkt open te staan op de Mac, bijvoorbeeld, of het netwerk valt even uit).
- Resultaat: Mac geeft een foutboodschap; de move-operatie wordt afgebroken; de files die al gemoved waren, worden verwijderd van de doel-locatie, en niet meer teruggeplaats op de bronlocatie.
Dat is me nu net overkomen, met tien files van elk rond een gigabyte groot. Geselecteerd op computer één, gemoved naar computer twee, Snow Leopard (achterlijke cutesy namen ook altijd) dénkt dat de negende file in de rij ergens open staat op computer één, waardoor die niet gemoved kon worden. Résultat des courses: acht van de tien files zijn wég. Ze staan niet meer op de broncomputer, en ze staan ook niet op de doelcomputer.
Ik vind dat redelijk bescheten, ja. En het is nog maar eens het zoveelste voorbeeld van dubbele standaarden: een OS-bug als dit op Windows, en de wereld zou te klein zijn. Data-verlies bij standaard-bestandsoperaties verdomme, dat is toch niet gepermitteerd?
update: een klein beetje zoeken op het internet brengt aan het licht dat dit soort fatale fouten geen uitzondering zijn op Mac. Dit specifieke probleem is perfect reproduceerbaar en treedt al jaren op. Fuck.
En een aantal van de reacties op bovenstaande link zijn typisch voor Mac-zeloten:
steven fisher (november 5th, 2007)
This was in Tiger, too. Does Apple actually document that you can hold down the command key to move the file instead of copying? (Not that I think it shouldn’t be fixed, but I’m a little less concerned if a feature that doesn’t officially exist doesn’t work well.)
(bestanden moven door command-sleep te doen zou een “niet officieel bestaande feature” zijn, wa ha ha)
snak (november 5th, 2007)
Good reason to stay away from anything Windows.
(het “probleempje” treedt ook op bij copiëren naar pakweg een USB-drive, dickwad)
zimmie (november 5th, 2007)
I wouldn’t call this a massive data loss bug. You have to go out of your way to move a file to a remote share rather than copy it […] you have to be doing something weird to encounter the bug.
(serieus? files moven is “something weird”? welkom in de grotemensenwereld — maar wacht, wacht: het kan nog achterlijker!)
hamranhansenhansen (november 5th, 2007)
The bug to me is that there is a move command at all between volumes. You can’t move stuff between volumes, only copy it.
(ik vind het niet uit, echt niet — die “zimmie” legt zijn belachelijke standpunt zelfs nog wat meer uit:)
zimmie (november 6th, 2007)
It’s going out of your way because you have to do extra work to do it. Most people would never think to hold down a modifier key while dragging files. I didn’t even know that there was a way to move files between volumes until I heard about this. […]I’m with hamranhansenhansen. The bug is the fact that the Finder lets you move things between volumes at all, not that it fails under some circumstances. It should be fixed by eliminating the move operation.
(ik heb geen woorden)
kenny (november 7th, 2007)
Have you never heard of http://bugreport.apple.com rather than showing your dirty laundry in public?
(aargh)
Het punt is: Mac OS X doet bij een move van files tussen volumes blijkbaar geen check na de move. En als er een probleem is, verwijdert hij alle al gemovede files. Wat hij zou moeten doen: move file 1, check of file 1 goed gemoved is, als in orde: verwijder file 1; move file 2, check of file 2 goed gemoved is, als in orde: verwijder file 2; move file 3, check of file 2 goed gemoved is, als niet in orde: operatie afbreken.
Niet move file 1, verwijder file 1; move file 2, verwijder file 2; move file 3, oei een probleem: verwijder file 1 en file 2 waar ze nu staan.
Leutig. Danku Macintosh.
Reacties
8 reacties op “Move naar nergens, of: fuck Macintosh”
Hallucinant.
Ik heb dat probleem nooit voor gehad toen ik nog met een Mac werkte, omdat het toch eigenlijk ook nooit in mij opkwam om bestanden meteen te verplaatsen tussen twee schijven. Als ik dingen verplaats (ongeacht via welk besturingssysteem) tussen computers of van een externe schijf naar een computer of omgekeerd kopieer ik sowieso eerst de bestanden en daarna wis ik ze indien nodig van de bronlocatie. Het lijkt me gewoon zo één van die logische voorzorgsmaatregelen te zijn waarvan ik dacht dat iedereen ze standaard toepaste.
Wat niet betekent dat het niet een beetje absurd is dat zo’n bug bestaat natuurlijk, en nee, ik ben geen Mac fan (meer) 🙂
Wat ik dus niet begrijp is dat ze geen tijd steken in Finder verbeteren. (1) Ik mis me altijd in de column view van kolom (na 4 jaar Mac) (2) Een file slepen in een kolom die al vol staat verreist pixel precision (3) De rampzalige shares functionaliteiten (4) Hetgeen jij beschrijft.
Waar komen ze elk jaar mee af? Nieuwe versies van iPhoto en Pages en Numbers. Nu lijken alle dev resources in iPad/iPhone te steken.
Zoek maar eens op Google op Error code -36 mac. Plezier gegarandeerd.
De redenen waarom ik terug Windows zou gebruiken:
1. PC gaming
2. MS Office
3. Windows Explorer
Ha, wel, ik ging ervan uit dat het OS dat deed voor mij: eerst copiëren, dan nakijken, dan pas verwijderen.
De échte smerigheid hier is natuurlijk dat zelfs correct gecopieerde bestanden verwijderd worden.
Ok, jij hebt nood aan
wat ontspanning.
It’s funny cos it’s true.
It just works. Wat een WTF.
Tune in next week wanneer Michel op OS X een folder naar ergens kopieert waar er al één met dezelfde naam staat en denkt dat er een merge van de folderinhoud zal gebeuren 🙂
Hint: geen merge. Wel de originele map (met content) foetsie!
Nieuwsflits: ik gebruik al meer dan twintig jaar meer dan regelmatig Macintoshen. Dát stukje idiotie wist ik al een eeuwigheid.
Dat is een interface-keuze, geen bug. Een stomme interface-keuze, maar wat er ook van weze: “works as advertised”. Die move-naar-nergens is géén keuze maar een stomme, stomme, zeer, zeer grote file.