Есть многое на свете....
А вот возьмем OS X Sierra. Есть один (то есть единственный) пользователь, на компьютере которого не работает такой вот код:
QString xmpfile = ....; // вычислить имя XMP из имени raw
QFile xmpw(xmpfile);
if (!xmpw.open(QIODevice::WriteOnly)) -> тут обрабатываем ошибку
И ошибка - EACCESS, прав нету
А вот такой вот код работает:
QString xmpfile = ....; // вычислить имя XMP из имени raw
int fd = open(xmpfile.toUtf8().data(), O_WRONLY | O_CREAT | O_TRUNC, 0664);
То есть открывается дескриптор и туда без проблем удается записать. xmpfile в обоих случаях, естественно, одинаковая строка.
И такой юзер у нас, повторяю, один, у всех остальных - все работает по первому варианту. И на Sierra и вообще везде.
Вопрос, блин: что это такое может быть то? Исходники QFile читал, оно транслируется в результате в fopen64 (да buffered IO в Qt работает через FILE), ну не должно же быть так, что fd работает, а FILE - нет?
Это все у юзера на ноутбуке, залезть туда отладчиком никакой возможности нет.
Я добавил ему распечатку прав на файлы при ошибке, все права на месте: право писать в каталог есть, файла создаваемого нет, все должно (бы) работать по первому варианту.
UPD: важно: создаваемый файл не существует. Так то можно было бы предположить блокировки и что QFile их как-то умеет обрабатывать, например.
Comments
Проверь по всему пути до
Проверь по всему пути до текущего каталога право на 'r-x'.
Читать списки файлов можно -
Читать списки файлов можно - иначе бы в этот каталог программа не попала бы никак.
Пройти (x) и читать (r) --
Пройти (x) и читать (r) -- две большие разницы. ;-)
Потом проверить -- HFS у клиента caseless or case sensitive.
Оно и прошло и читало -
Оно и прошло и читало - скриншоты то у меня есть, там дерево фолдеров отображено, значит и пройдено и прочитано.
про caseless - хороший добрый вопрос, но опять же, open работает, fopen - нет?
Значить имя записываемого
Значить имя записываемого файла не одинаковое (locale?).
Ну немец, да, может и locale
Ну немец, да, может и locale
С другой стороны, вот там же utf8 все?
То есть я вот у себя пробовал
То есть я вот у себя пробовал (и на 10.9 и на сьерре) - запись русского имени файла и запись немецкого - дает вроде как неотличимые глазом результаты, что старым кодом, что новым.
Но вообще, не проходит
Но вообще, не проходит гипотеза:
could not open file "/Volumes/Images/2015/Poppy House & Birds/_NIK2398.xmp"
Я не вижу тут ни одного нечеловеческого символа
совсем дурной вопрос
umask и extended attributes?
Так чтобы open - да, а fopen
Так чтобы open - да, а fopen - нет?
[sd]trace? Какой сисколл в
[sd]trace? Какой сисколл в итоге вызывается в случае fopen64?
Ну на клиентской машине без
Ну на клиентской машине без шансов узнать.
А зависит, по всей видимости, именно от клиентского окружения.
ну почему же без шансов
Это ж мак? тогда там есть dtrace!
Есть. Но там еще юзер есть.
Есть. Но там еще юзер есть.
Ну, нарисовать ему dtrace
Ну, нарисовать ему dtrace скрипт, который поймает и покажет тебе эти вызовы, раз уже не ktrace/strace?
1) Нарисовать скрипт
1) Нарисовать скрипт
2) Заставить выполнить нужные действия
При том, что юзерская проблема зачинена (через open) и он с радаров пропал
Может быть некоей проблемой...
Гипотеза 1: имя файла с
Гипотеза 1: имя файла с precomposed и раздельными буквами Юникода. На маке буква ё состоит из двух юникодных символов, помню как с rsync маялся.
Гипотеза 2: право на запись в каталог: оно там невидимые файлы ._foobar создаёт
Занимается ли fopen нормализацией Юникода или удалением/созданием ресурсных фортов не знаю, не читал, но осуждаю :)
Ну то есть вот предположение
Ну то есть вот предположение пока такое, что внутри QFile() с уникодом не все в порядке, зато вот QString::toUtf8() все делает как надо.
Мда. Возможно, конечно. Хотя в тех примерах что от юзера приходят (в комментариях выше есть) - чистая латиница, ни одного умляута я не вижу.
А пробельные символы состоят
А пробельные символы состоят из истинных пробелов™ ? Вдруг там какой-нибудь или ? Unicode consortium без зарплаты останется, если ещё один-два пробельных символа не придумает в очередном обновлении стандарта.
В любом случае EACCESS, как мне кажется, должен быть связан с правами на доступ к каталогу. Захотелось им, например, переименовать файл в более каноническое имя в процессе открывания, или все эти параллельные ресурсные форки как-нибудь расшить/сшить, а прав нет.
Истинность пробелов я в логах
Истинность пробелов я в логах не вижу, естественно, особенно после прохождения через пару E-mail клиентов.
дикое нубское предположение
Может, версия libc какая-нибудь экзотическая? товарищ с любопытным эффектом не замечен в установке экзотических софтов?
Это запросто может быть, к
Это запросто может быть, к примеру, (кривой) антивирус. Вне всяких сомнений.
Но так как проблема юзера решена (выпуском под него персонального патча) - пока остается только любопытство "что это было"