|
Может ли FSO "увидеть" слишком длинные имена файлов?
|
|||
---|---|---|---|
#18+
Доброго времени суток. Моя старая задача с новой проблемой: От клиентов приходят архивы произвольной структуры. Пользователи распаковывают их в каталоги, имеющие свою сложную структуру. Имена (перечень) файлов нужно занести в базу Access. Пользователь в Access-овском приложении выбирает подкаталог и дальше Access с помощью FSO сканирует его содержимое и составляет список файлов. Беда в том, что каким-то, неисповедимым мне способом, иногда случается так что суммарная длина пути и файла превышает максимально допустимую (несмотря на то, что они спокойненько лежат в каталоге). И в этом случае FSO их просто "не замечает". Т.е., например, в каком-то подкаталоге лежит 20 файлов: 10 с короткими именами и 10 со слишком длинными. FSO видит только те 10, у которых короткие имена. И никаких сообщений об ошибках. Мне нужно каким-то образом ловить такие ситуации. М.б. кто-нибудь что-нибудь подскажет? Заранее благодарен. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2018, 18:05 |
|
Может ли FSO "увидеть" слишком длинные имена файлов?
|
|||
---|---|---|---|
#18+
Проверил. Точно, длинные пути не определяет. Почему? Не знаю. Попробуйте вот этот код Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Длинные имена читает. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2018, 10:38 |
|
Может ли FSO "увидеть" слишком длинные имена файлов?
|
|||
---|---|---|---|
#18+
K-NickИ в этом случае FSO их просто "не замечает"Просто ошибка объекта не транслируется в программу. Реализуй тот же блок кода, но на VBS - получишь сообщение об ошибке и хоть какую-то информацию к размышлению... ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2018, 10:54 |
|
Может ли FSO "увидеть" слишком длинные имена файлов?
|
|||
---|---|---|---|
#18+
В любом случае я бы порекомендовал отказаться от FSO и опуститься до FindFirstFileW/FindNextFileW. Они точно без проблем читают имена в 32 кб длиной... ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2018, 11:07 |
|
Может ли FSO "увидеть" слишком длинные имена файлов?
|
|||
---|---|---|---|
#18+
А лучше сначала приведи здесь блок своего кода. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2018, 11:09 |
|
Может ли FSO "увидеть" слишком длинные имена файлов?
|
|||
---|---|---|---|
#18+
AkinaВ любом случае я бы порекомендовал отказаться от FSO и опуститься до FindFirstFileW/FindNextFileW. Они точно без проблем читают имена в 32 кб длиной... Большое Спасибо! У меня FindFirstFileW/FindNextFileW тоже не видят слишком длинных путей к файлам, но они возвращают информацию об ошибке. Это уже значительно лучше. Почему-то я почти не нашел примеров использования этих функций с VBA, только вот здесь (если кому-нибудь понадобится) неплохой пример: https://www.experts-exchange.com/questions/21775294/Using-FindFirstFileW-and-FindNextFileW.html И не нашел ни одного примера с использованием CreateDirectotyW (Если уж отказываться от FSO - то отказываться). Почему-то он не всегда создает каталоги. Без видимых причин. И GetLastError возвращает 0 Использую так: Код: vbnet 1.
Не подкинете ли, великодушно, примерчик или ссылку? Заранее премного благодарен. (Я в WinAPI-шных функциях не силен только вчера начал рыться) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2018, 16:44 |
|
Может ли FSO "увидеть" слишком длинные имена файлов?
|
|||
---|---|---|---|
#18+
K-NickМ.б. кто-нибудь что-нибудь подскажет? Заранее благодарен. 1. Если нужны только имена файлов, можно не распаковывать архив, а использовать возможность архиватора сформировать этот список в отдельный файл/консоль. 2. Можно использовать команду subst для сокращения имени файла: subst x: c:\VeryLongPath, затем работать с виртуальным диском x: 3. Попробовать к началу пути добавить 5 символов \\?\ ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2018, 22:26 |
|
|
start [/forum/topic.php?fid=45&gotonew=1&tid=1611539]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
48ms |
get topic data: |
10ms |
get first new msg: |
8ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
others: | 273ms |
total: | 415ms |
0 / 0 |