Привет!

Есть каталог, я в него хожу туда-сюда, хоть в фаре, хоть в проводнике.

Но

template<> inline bool isPathDirectory<std::string>( const std::string &path )
{
    DWORD attrs = ::GetFileAttributesA(path.c_str());
    if (attrs==INVALID_FILE_ATTRIBUTES)
    {
        return false;
    }

    if (attrs & FILE_ATTRIBUTE_DIRECTORY)
    {
        return true;
    }

    return false;
}

с какого-то перепугу возвращает фолс.

В отладчике посмотрел, GetFileAttributesA возвращает 0x2020:

#define FILE_ATTRIBUTE_ARCHIVE              0x00000020  
#define FILE_ATTRIBUTE_NOT_CONTENT_INDEXED  0x00002000

а для каталогов вроде должно стоять это:

#define FILE_ATTRIBUTE_DIRECTORY            0x00000010

В фаре смотрю атрибуты — установлен только "неиндексируемый". Атрибут "архивный" — не установлен.

Смотрю свойства в проводнике — а он мне говорит, что это папка с файлами, и что у неё стоит атрибут "только для чтения"

Я где-то протупил, похоже, но где?

П>с какого-то перепугу возвращает фолс.

А что GetLastError() возвращает (и почему он в коде не прверяется)?

Здравствуйте, m2user, Вы писали:

П>>с какого-то перепугу возвращает фолс.

M>А что GetLastError() возвращает (и почему он в коде не прверяется)?

А с чего его проверять? Проверяется результат вызова GetFileAttributesA на INVALID_FILE_ATTRIBUTES, и там всё нормасик.

В доке пишут, что:

If the function fails, the return value is INVALID_FILE_ATTRIBUTES. To get extended error information, call GetLastError.

Здравствуйте, пффф, Вы писали:

П>Привет!

П>Есть каталог, я в него хожу туда-сюда, хоть в фаре, хоть в проводнике.

П>Но

Переделал через FindFirstFile — и всё стало нормально. Но, чисто для интереса, хотелось бы узнать, где говно порылось

Здравствуйте, пффф, Вы писали:

П>Есть каталог, я в него хожу туда-сюда, хоть в фаре, хоть в проводнике.

Что за путь-то?

Здравствуйте, ArtDenis, Вы писали:

П>>Есть каталог, я в него хожу туда-сюда, хоть в фаре, хоть в проводнике.

AD>Что за путь-то?

F:\projects\project-group\project\doc\doxy

Как-то так.

Ни пробелов, ни нац символов в путях нет

Здравствуйте, пффф, Вы писали:

П>F:\projects\project-group\project\doc\doxy

F: это не RAM-диск? В пути нету ссылки?

Здравствуйте, ArtDenis, Вы писали:

П>>F:\projects\project-group\project\doc\doxy

AD>F: это не RAM-диск? В пути нету ссылки?

Нет, это старый добрый HDD

Здравствуйте, пффф, Вы писали:

П>

П>template<> inline bool isPathDirectory<std::string>( const std::string &path )
П>{
П>    DWORD attrs = ::GetFileAttributesA(path.c_str());
П>    if (attrs==INVALID_FILE_ATTRIBUTES)
П>    {
П>        return false;
П>    }

П>    if (attrs & FILE_ATTRIBUTE_DIRECTORY)
П>    {
П>        return true;
П>    }

П>    return false;
П>}
П>

П>с какого-то перепугу возвращает фолс.

П>В отладчике посмотрел, GetFileAttributesA возвращает 0x2020


П>Смотрю свойства в проводнике — а он мне говорит, что это папка с файлами, и что у неё стоит атрибут "только для чтения"

Для информации: в Проводнике атрибуты каталогов не отображаются, там консолидируются атрибуты внутри лежащих файлов.


Касательно исходной проблемы, ситуация странная, конкретных идей относительно источника проблемы нет. Я бы начал последовательно устранять все потенциальные источники:
а) Избавиться от всяких string'ов и преобразований, передать тупо константную сишную строку с целевым путём. Вообще, лучше написать отдельную сишную прожку, которая вызывает эту функцию и печатает ответ, и больше вообще ничего не делает. А то мало ли какие сайд-эффекты от другого кода могут быть.
б) Проверить GetFileAttributesW.
в) Проверить GetFileAttributesExA/W.
г) Убедиться, что это не reparse point. Конечно, должен был бы присутствовать FILE_ATTRIBUTE_REPARSE_POINT=0x400, но шут его знает…
д) Диск F: — самый обычный локальный раздел, NTFS? Промежуточные элементы этого пути тоже не являются какими-нибудь точками монтирования или симлинками чёрт знает куда?

П>А с чего его проверять? Проверяется результат вызова GetFileAttributesA на INVALID_FILE_ATTRIBUTES, и там всё нормасик.

Как я понял, был ещё и запуск без отладчика, где не очевидно по какому условию функция вернула false.
Поэтому имеет смысл хотя бы трассировку GetLastError() производить.

Добавлю также, что:
1) отладка может идти в другом security контексте, чем запуск без отладки, что может влиять на успешность чтения атрибутов
2) листинг родительской директории тоже требует иных прав, чем чтение метаданных отдельного подкаталога/файла

Впрочем ситуацию это не объясняет.

Здравствуйте, CaptainFlint, Вы писали:

CF>г) Убедиться, что это не reparse point. Конечно, должен был бы присутствовать FILE_ATTRIBUTE_REPARSE_POINT=0x400, но шут его знает…

Не reparse point


CF>д) Диск F: — самый обычный локальный раздел, NTFS? Промежуточные элементы этого пути тоже не являются какими-нибудь точками монтирования или симлинками чёрт знает куда?

Самый простой тупой путь на локальном HDD диске NTFS, никаких точек монтирования и репарс поинтс там нет, тупо каталог в NTFS файловой системе

Сделал обходняк через FindFirstFile, работает

Потом все твои остальные идеи возможно проверю, но пока FindFirstFile работает нормас

Здравствуйте, m2user, Вы писали:

M>Как я понял, был ещё и запуск без отладчика, где не очевидно по какому условию функция вернула false.

Конечно был.


M>Поэтому имеет смысл хотя бы трассировку GetLastError() производить.

Но какой смысл следить за GetLastError(), если функция АПИ отработала без ошибок?


M>Добавлю также, что:
M>1) отладка может идти в другом security контексте, чем запуск без отладки, что может влиять на успешность чтения атрибутов
M>2) листинг родительской директории тоже требует иных прав, чем чтение метаданных отдельного подкаталога/файла

M>Впрочем ситуацию это не объясняет.

А то

Здравствуйте, пффф, Вы писали:

П>Есть каталог, я в него хожу туда-сюда, хоть в фаре, хоть в проводнике.

Попробовать добиться стабильного воспроизведения, потом смотреть на ProcessMonitor.

А ещё, не стоит ли у вас антивируса? А от MS?

Здравствуйте, пффф, Вы писали:

П>Нет, это старый добрый HDD

Сделай ему старый добрый chkdsk на всякий случай. Не то, чтобы, но всё же.

Здравствуйте, Слава, Вы писали:

П>>Есть каталог, я в него хожу туда-сюда, хоть в фаре, хоть в проводнике.

С>Попробовать добиться стабильного воспроизведения, потом смотреть на ProcessMonitor.

Ну, вполне стабильно воспроизводится. А что смотреть в ProcessMonitor?


С>А ещё, не стоит ли у вас антивируса? А от MS?

Сторонних нет, родной дефендер или как его — стоит, чего-то вроде проверяет

Здравствуйте, CaptainFlint, Вы писали:

CF>Для информации: в Проводнике атрибуты каталогов не отображаются, там консолидируются атрибуты внутри лежащих файлов.

Разве?

У меня в том каталоге нет вообще никаких файлов, но проводник показывает, что только для чтения. Но создавать там файлы и удалять их, а также читать/писать я могу

Здравствуйте, Sharowarsheg, Вы писали:

П>>Нет, это старый добрый HDD

S>Сделай ему старый добрый chkdsk на всякий случай. Не то, чтобы, но всё же.

Никаких проблем не нашлось

Здравствуйте, пффф, Вы писали:

CF>>Для информации: в Проводнике атрибуты каталогов не отображаются, там консолидируются атрибуты внутри лежащих файлов.

П>Разве?

П>У меня в том каталоге нет вообще никаких файлов, но проводник показывает, что только для чтения. Но создавать там файлы и удалять их, а также читать/писать я могу

У "только для чтения" он показывает не выставленное состояние (галочку), а неопределённое (заполненный квадратик). В диалоге свойств папки эта опция применяется не для показа, а только для изменения атрибутов, причём не самого каталога, а именно внутри лежащих файлов, что подчёркивается текстом у этого контрола ("Read-only (Only applies to files in fodler)"). Проверить и/или поменять атрибут "только для чтения" самого каталога через этот диалог невозможно, нужны другие инструменты (командная строка, нормальные файловые менеджеры). Несмотря на то, что при попытке выставить галочку он предлагает диалог с вариантом "Apply changes to this folder, subfolder and files" — это он врёт, "только для чтения" применится только к файлам. (Как я понимаю, просто задействовали одинаковый диалог подтверждения для разных ситуаций.)

Кроме того, атрибут "только для чтения" у каталога не означает, что туда нельзя писать. Собственно, для каталога этот атрибут вообще ничего не значит; по крайней мере, сейчас. Уже не помню, как было в MS-DOS. Конкретно в Проводнике этот атрибут каталога (наравне с "системным") может применяться как маркер стилизации: если этот атрибут выставлен и в каталоге имеется файл desktop.ini со спец-информацией, то к каталогу будут применены стили, заданные в этом desktop.ini (значок, описание, фон и пр.).

Здравствуйте, пффф, Вы писали:

П>Ну, вполне стабильно воспроизводится. А что смотреть в ProcessMonitor?

Всё, связанное с этим каталогом. Кто-то же вам отвечает вот таким образом.

Здравствуйте, пффф, Вы писали:

Обнаружил такую фигню: если сам создаю каталог через CreateDirectoryA/CreateDirectoryW — атрибут каталога не создаётся. Но и Far и проводник видят каталог, можно файлы создавать, нормальный каталог в общем. Но потом когда я делаю либо FindFirstFile, либо GetFileAttributes — то флага FILE_ATTRIBUTE_DIRECTORY там нет. Само собой, при создании каталога я не устанавливаю этот атрибут