Дескриптор дубликата файла с его собственным файловым смещением

Контроллер представления, который помещается в стек контроллеров навигации, имеет для параметра hidesBottomBarWhenPushing значение yes.

1. Преобразовать дескриптор файла в собственный дескриптор файла с помощью _get_osfhandle ()
2. Получить имя файла с помощью GetFileInformationByHandleEx (FILE_NAME_INFO) ¹
3. Используйте CreateFile, чтобы открыть новый дескриптор этого файла
4. Создать файловый дескриптор для этого дескриптора с _open_osfhandle ()

Et voilà , у нас есть новый файловый дескриптор, ссылающийся на тот же файл, но с его собственными разрешениями, положением и т. д.

К концу вашего вопроса , вы говорите так, будто вам также нужны «разрешения», но это, похоже, не имеет никакого реального смысла - разрешения прикрепляются к самому файлу, а не к тому, как файл открывается, поэтому открытие или повторное открытие файла имеет не влияет на права доступа к файлу. Если вы действительно хотите знать, вы можете получить его с помощью GetFileInformationByHandle, но имейте в виду, что права доступа к файлам в Windows несколько отличаются от (традиционных) прав доступа к файлам в Unix. Unix имеет права владельца / группы / мира для всех файлов, и в большинстве систем также есть ACL (хотя есть и другие варианты их работы). Windows либо вообще не имеет разрешений (например, файлы в FAT или FAT32), либо использует ACL (например, файлы в NTFS), но ничего, что действительно эквивалентно традиционным разрешениям владельца / группы / мира, к которым большинство людей привыкло в Unix.

Возможно, вы используете «разрешения», чтобы указать, был ли файл открыт для чтения, записи или того и другого. Получение этого значительно уродливее, чем любое из предыдущих. Проблема в том, что большая часть этого находится в библиотеке, а не в Win32, поэтому, вероятно, нет способа сделать это, даже близко к переносимому между компиляторами. С MS VC ++ 9. 0 SP1 (не гарантируется для любого другого компилятора), вы можете сделать это:

#include <stdio.h>

int get_perms(int fd) {
    int i;
 FILE * base = __iob_func();

    for (i=0; i<_IOB_ENTRIES; i++) 
        if (base[i]._file == fd)
            return base[i]._flag;     // we've found our file
    return 0; // file wasn't found.
}

Поскольку это потребовало некоторого анализа, я написал быстрый тест, чтобы убедиться, что он действительно может работать:

#ifdef TEST
#include <io.h>

void show_perms(int perms, char const *caption) { 
 printf("File opened for %s\n", caption);
 printf("Read permission = %d\n", (perms & _IOREAD)!=0);
 printf("Write permission = %d\n", (perms & _IOWRT)!=0);
}

int main(int argc, char **argv) { 
 FILE *file1, *file2;
 int perms1, perms2;

 file1=fopen(argv[1], "w");
 perms1 = get_perms(_fileno(file1));
 fclose(file1);

 file2=fopen(argv[1], "r");
 perms2 = get_perms(_fileno(file2));
 fclose(file2);

 show_perms(perms1, "writing");
 show_perms(perms2, "reading");
 return 0;
}
#endif

И результаты кажутся для обозначения успеха:

File opened for writing
Read permission = 0
Write permission = 1
File opened for reading
Read permission = 1
Write permission = 0

Затем вы можете проверить этот возвращенный флаг на _IOREAD, _IOWRT и _IORW, которые определены в stdio.h. Несмотря на мои предыдущие предупреждения, я, вероятно, должен указать, что подозреваю (хотя, конечно, не могу гарантировать), что эта часть библиотеки достаточно стабильна, поэтому реальные шансы на серьезные изменения, вероятно, довольно минимальны.

С другой стороны. направление, однако, практически нет шансов , что он будет работать с любой другой библиотекой. Он может (но определенно не гарантирует) работать с другими компиляторами, использующими библиотеку MS, такими как Intel, MinGW или Comeau, использующие MS VC ++ в качестве серверной части. Из них я бы сказал, что с наибольшей вероятностью сработает Comeau, а наименее всего - MinGW (но это только предположение; велика вероятность, что это не сработает ни с одним из них).

1. Требуется распространяемый Win32 FileID API Library