Комната Джеймса Пинкстоуна, рядом с рабочим компьютером
Американский композитор-фрилансер Джеймс Пинкстоун прославился на весь интернет, когда опубликовал резонансную статью «Apple украл мою музыку. Нет, серьёзно». Статья вышла 4 мая и вызвала бурное обсуждение в интернете. Джеймс возмущался, что через 8 месяцев после подписки на сервис Apple Music программа iTunes внезапно удалила с жёсткого диска 122 гигабайта файлов, заменив их на копии в облачном хранилище.
Спустя несколько дней Apple официально признала наличие бага в программном обеспечении iTunes. Но при этом программисты компании не смогли воспроизвести ошибку, поэтому не знают, как исправить баг. Вот почему двое сотрудников Apple пришли домой к Джеймсу Пинкстоуну в субботу 14 мая. Целый день они пытались повторить сценарий с удалением файлов, но ничего не получилось.
Джеймс говорит, что пустил домой представителей Apple после того как они заслужили его доверие, не подвергая сомнению факт ошибки в программном обеспечении и не высказывая версии, что это может быть пользовательская ошибка.
Кроме того, Джеймс поставил условие: не копаться в компьютере, а ограничить исследование строго Apple Music, iTunes и коллекцией файлов iTunes. Если они увидят на компьютере какие-то предположительно пиратские файлы, они обещают не изучать их и не упоминать в отчёте. Сотрудники Apple согласились с таким условием.
Для расследования Том и Эзра (так зовут специалистов) принесли с собой специальную версию iTunes, которая ведёт детализированный лог событий в системе.
На первом этапе Джеймс под надзором представителей Apple заново зарегистрировался в Apple Music. Во время этой процедуры Том и Эзра установили конференц-связь с опытными программистами из офиса Apple в Калифорнии, обсуждая каждый шаг.
Пообедав в местном кафе (сотрудники Apple купили Джеймсу бутерброд), они несколько часов совершали различные действия в iTunes, но программа так и не удалила файлы. В конце концов, сотрудники покинули дом композитора, но оставили ему домашнее задание: купить песни в магазине iTunes Store, импортировать некоторые из песен собственного сочинения из Logic и/или Pro Tools, повозиться с плейлистами и транслировать видео из личной библиотеки на Apple TV в гостиной.
На следующий день Том вернулся один, чтобы скопировать записанные логи и удалить все следы чужого присутствия в системе. Джеймс Пинкстоун говорит, что после ухода гостей на всякий случай полностью удалил содержимое диска и установил все программы заново из резервной копии, которую предусмотрительно сделал перед визитом сотрудников Apple.
В общем, несмотря на все усилия, зловредный баг пока никак не удаётся найти.
Комментарии (36)
Boctopr
18.05.2016 18:36+1Про картинку это не
Комната Джеймса Пинкстоуна, рядом с рабочим компьютером
А нога Джеймса Пинкстоуна, рядом с рабочим компьютером, который мы не видим
Old_Chroft
18.05.2016 19:12+1На фото на самом деле шесть ног (не считая лап тузика) и одна рука под задницей :-)
mayorovp
18.05.2016 19:15+2Мне одному заголовок напомнил о Сакстоне Хейле и его "политике" работы с недовольными клиентами?
Perkin
18.05.2016 19:51-2Да просто сотрудники Apple баг под шумок пофиксили, но признать не могут. Вот и устроили цирк, мол у нас все в шоколаде, а вы все дураки.
dom3d
18.05.2016 19:53+1Оказывается композитор сам не понимает куда девал свои файлы.
Дедушка, наверное, старенький ужо.Mamonty
18.05.2016 22:57+6Вы заблуждаетесь, если предполагаете, что в русском языке слово «ужо» обозначает то же, что «уже».
Old_Chroft
19.05.2016 10:52перед «что» запятая лишняя. «ужо» из компьютерного сленга. «ужо старенький» — так наверное? (приглашаю граммар-наци)
avost
19.05.2016 12:05+1Вероятно, имеется в виду это (чОрт, а я тоже думал, что «ужо» — это искаверканое «уже»):
ужо?
I нареч. обстоят. времени разг.-сниж.
Как-нибудь, на досуге; позже, пото?м.
II предик. разг.-сниж.
Обозначение угрозы мести или наказания как действия.
III межд. разг.-сниж.
Возглас, выражающий угрозу мести, наказания и соответствующий по значению сл.: дай срок! вот наступит время!
Толковый словарь Ефремовой. Т. Ф. Ефремова. 2000.
dnska
19.05.2016 13:38+2Все кричат: «Лови, лови,
Да дави ее, дави…
Вот ужо! постой немножко,
Погоди...» А князь в окошко,
Да спокойно в свой удел
Через море прилетел.
sens_boston
18.05.2016 21:30+1Заголовок для меня прозвучал созвучно пресловутому «доктора придётся послать. И зачистить все эти проблемы» (с) сами_знаете_кто :D
gotlium
18.05.2016 23:45+2Было бы правильнее, если бы он восстановил все из копии, после воспроизвел баг, и записал бы к примеру скринкаст. Не в защиту, но с точки зрения тестирования — действительно нужно доказать наличие бага и воспроизвести его независимо. В итоге и он не доказал, и они воспроизвести не смогли.
Smagold
19.05.2016 08:59Если этот баг все-таки и был, то совсем не обязательно что это был сам iTunes. Могу предположить, что при синхронизации файлов с облаком, iTunes добавляет метки к файлу, которые мог считать антивирус или чистильщик типа CCleaner / CleanMyMac etc, и посчитать их «ненужным мусором». Так как Apple уже делали заявление о проверке кода всей программы, думаю, команду file.delete (грубо), разработчики бы точно не упустили.
Или тогда такой вопрос к экспертам файловых систем: мог ли диск, под большой нагрузкой считывания, заблокировать или даже выпилить весь раздел с теми 122 гб файлов, или тогда скорее бы сам диск полностью превратился в кирпич?
TimsTims
19.05.2016 10:48А я считаю, что в Apple не дураки сидят, и очевидные вещи про file.delete они уж точно проверили.
А что если там создается несколько потоков threads, которые синхронно работают с разными файлами, затем в какой-то момент при очень редкой ситуации происходит переполнение буфера, и вместо 0(не удалять) приходит 1(удалить)? И такую ситуация логически чтением кода и заранее подготовленными тестами никак не отследить — буфер никогда в определенных местах не переполнялся, к такому поведению программы ничто не приводило… Вот и ищут всем отделом ошибку в iTunes
Опять-же Apple уже признала такую ошибку, а это уже означает, что проблема на их стороне.
scronheim
19.05.2016 09:23+2оставили ему домашнее задание: купить в песни iTunes Store
Это было главной задачей прихода:)
kalmarius
19.05.2016 10:04Напомнило баян с Баша: «Слыш, сука, мы знаем кто ты и зачем звонил! Щас все починим!»
Gunnar
19.05.2016 15:53+9С включенными логами никогда ничего не воспроизводится
isden
20.05.2016 14:33А таки реально видел такое.
В некоем софте под одной древней версией PHP наблюдался «проскок» через цикл while (в теле цикла была простая мат.операция). При добавлении логгера в тело цикла — все отлично работало.
bkotov
Даже странно… Может это просто по тому что товарищ решил попиариться и никакого бага не было?
Jamato
Так он же не один. И тогда официального признания бага не было бы.
Shannon
Потому что apple не признала наличие бага, а допустила наличие такой возможности (и теперь пытается хотя бы один раз воспроизвести его)
nubko
Типичный баг Гейзенберга
Orcus13
Шредингер расстроен вашим коментом.
mayorovp
Почему?
Orcus13
Незаслуженно забыт его домашний питомец
Dentty
Гейзенбаг
Кот Шрёдингера, всё же, немного про другое
Mad__Max
Вау, оказывается термин такой есть.
Раньше такое называл либо «блуждающий глюк» или «фантомный баг».
Сталкиваюсь с таким регулярно, сотрудники (в фирме где по совместитительсву админил/эникеил), родственники, знакомые жалуются на баг/глюки/некорректную работу чего-либо. Прихожу смотреть лично — уже все работает, воспроизвести не получается. После моего ухода иногда возвращается, но обычно уже нет.
Уже закрепились шутки о том, что баги (или вообще компы) меня боятся и в моем присутствие сразу начинают работать хорошо, а мелкие баги умирают только от моего вида. Так же иногда подшучивают: «как ты это делаешь без бубна?!»
Гейзенбаг это просто отлично для такого явления.
Правда звучит не очень и большинство не поймет о чем речь без объяснений…
Tacgnol
В точности та же фигня. Особенно про лечение багов присутствием.
alex_blank
Гейзенбаг
Wesha
Товарищу немножечко заплатил Seagate и прочие производители backup-решений :)