Есть многое на свете....

А вот возьмем 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) -- две большие разницы. ;-)

Потом проверить -- HFS у клиента caseless or case sensitive.

Оно и прошло и читало - скриншоты то у меня есть, там дерево фолдеров отображено, значит и пройдено и прочитано.

про caseless - хороший добрый вопрос, но опять же, open работает, fopen - нет?

Значить имя записываемого файла не одинаковое (locale?).

Ну немец, да, может и locale

С другой стороны, вот там же utf8 все?

То есть я вот у себя пробовал (и на 10.9 и на сьерре) - запись русского имени файла и запись немецкого - дает вроде как неотличимые глазом результаты, что старым кодом, что новым.

Но вообще, не проходит гипотеза:
could not open file "/Volumes/Images/2015/Poppy House & Birds/_NIK2398.xmp"
Я не вижу тут ни одного нечеловеческого символа

umask и extended attributes?

Так чтобы open - да, а fopen - нет?

[sd]trace? Какой сисколл в итоге вызывается в случае fopen64?

Ну на клиентской машине без шансов узнать.

А зависит, по всей видимости, именно от клиентского окружения.

Это ж мак? тогда там есть dtrace!

Есть. Но там еще юзер есть.

Ну, нарисовать ему dtrace скрипт, который поймает и покажет тебе эти вызовы, раз уже не ktrace/strace?

1) Нарисовать скрипт
2) Заставить выполнить нужные действия

При том, что юзерская проблема зачинена (через open) и он с радаров пропал
Может быть некоей проблемой...

Гипотеза 1: имя файла с precomposed и раздельными буквами Юникода. На маке буква ё состоит из двух юникодных символов, помню как с rsync маялся.

Гипотеза 2: право на запись в каталог: оно там невидимые файлы ._foobar создаёт

Занимается ли fopen нормализацией Юникода или удалением/созданием ресурсных фортов не знаю, не читал, но осуждаю :)

Ну то есть вот предположение пока такое, что внутри QFile() с уникодом не все в порядке, зато вот QString::toUtf8() все делает как надо.

Мда. Возможно, конечно. Хотя в тех примерах что от юзера приходят (в комментариях выше есть) - чистая латиница, ни одного умляута я не вижу.

А пробельные символы состоят из истинных пробелов™ ? Вдруг там какой-нибудь   или   ? Unicode consortium без зарплаты останется, если ещё один-два пробельных символа не придумает в очередном обновлении стандарта.

В любом случае EACCESS, как мне кажется, должен быть связан с правами на доступ к каталогу. Захотелось им, например, переименовать файл в более каноническое имя в процессе открывания, или все эти параллельные ресурсные форки как-нибудь расшить/сшить, а прав нет.

Истинность пробелов я в логах не вижу, естественно, особенно после прохождения через пару E-mail клиентов.

Может, версия libc какая-нибудь экзотическая? товарищ с любопытным эффектом не замечен в установке экзотических софтов?

Это запросто может быть, к примеру, (кривой) антивирус. Вне всяких сомнений.

Но так как проблема юзера решена (выпуском под него персонального патча) - пока остается только любопытство "что это было"