Jump to content
Muxe Inc Forums

Recommended Posts

Garl    0
2 hours ago, Guest WAJIM said:

Окно с цветами теперь не влазит в экран при ширине 80. :(

принято чуток подсократил названия пунктов...

собрал nightly версию

Share this post


Link to post
Share on other sites
Guest WAJIM   
Guest WAJIM
1 hour ago, Guest CandyMan said:

I just added option to disable execution of all files by Enter

Thanks! ;)

Share this post


Link to post
Share on other sites
Guest WAJIM   
Guest WAJIM
53 minutes ago, Garl said:

чуток подсократил названия пунктов..

Спасибо,  теперь жить можно. ;)

Share this post


Link to post
Share on other sites
Guest WAJIM   
Guest WAJIM

А поддержка просмотра файлов >2GB и Hex-редактора для файлов >2GB планируется?

 

Share this post


Link to post
Share on other sites
Guest Onion   
Guest Onion

...Я у Гарла спрашивал,
Что с большими файлами?
Долго Гарлыч слезы лил
За моим окном.

Share this post


Link to post
Share on other sites
Garl    0

У меня x64 версия. там проблем нет. В сторону поддержки больших файлов даже не смотрел. NDN - для меня это инструмент и хобби.

Пишем Candyman'у с вопросом по файлам >2Gb в 32 битной вресии

Share this post


Link to post
Share on other sites
Guest WAJIM   
Guest WAJIM

Если в имени файла есть юникод-символы или другие нехорошие символы (для примера - двойные боковые кавычки: << или >>), то NDN не может работать с такими файлами, даже удалить их не может. Приходится в тотале удалять нехорошие символы. Что-то планируется делать с этим?

Share this post


Link to post
Share on other sites
Garl    0

как предлагаете определять в неюникодовой программе юникодовые символы?

например тот же список файлов, что с ним делать?

Share this post


Link to post
Share on other sites
Garl    0

  fix: windows: correct show junction with PrintNameLength=0

что там ещё было по связям и ссылкам? smlinks\junction

Share this post


Link to post
Share on other sites
Guest WAJIM   
Guest WAJIM
4 hours ago, Garl said:

как предлагаете определять в неюникодовой программе юникодовые символы?

например тот же список файлов, что с ним делать?

А вы посмотрите, как FAR работает. Понятное дело, что в списке файлов только ANSI-символы можно использовать. Но FAR заменяет юникод-символы на вопросы, но нормально с ними работает. Удаление, переименование, просмотр - все работает.

Share this post


Link to post
Share on other sites
Garl    0

Если работать не с именами файлов а с хэндлами - тогда хоть чего можно выводить вместо имени файла. 

Share this post


Link to post
Share on other sites
Guest DRON   
Guest DRON
3 hours ago, Garl said:

обновил

Показ конечно работает, хотя я не уверен что префикс ?\ это тоже что и \??\ (который документирован как отключение нормализации). А главное удаление reparsepoints всё так же плохо работает. В старых версиях оно конечно тоже грохает все подпапки, но хотя бы следов не оставляет.

Share this post


Link to post
Share on other sites
Garl    0

Удаление не трогалось от слова "совсем". Сперва надо разобраться с отображением...

Тут такое дело nsx.exe отображает ссылку как \??\ , а DeviceIOControl отдаёт его как ?\

з.ы.

у  JUNCTION путь начитанется с ?\ а у SYMLINK с \??\

если сильно хочется видеть \??\ можно прилепить \? в начале, но лучше отложим до реализации создания\удаления\изменения ссылок

 

Про удаление нужно логику продумать:

-удаление единственной ссылки (лишний вопрос? удалять линк\источник)

-удаление ссылки встречающейся в списке

 

как то так...

Share this post


Link to post
Share on other sites
Guest DRON   
Guest DRON
4 hours ago, Garl said:

Тут такое дело nsx.exe отображает ссылку как \??\ , а DeviceIOControl отдаёт его как ?\

dir /al тоже \??\ показывает, так что там видимо бага в обработке того что возвращает DeviceIOControl.

4 hours ago, Garl said:

у  JUNCTION путь начитанется с ?\ а у SYMLINK с \??\

Да нифига: вызвал DeviceIoControl(FSCTL_GET_REPARSE_POINT) для обоих вариантов и получил в буфере \??\, так что точно бага.

Автор nsx обращает внимание, что:

Quote

Отличие junction от symlink в том, что PrintName и SubstituteName в буфере reparse_buf расположены в другом порядке, а длины строк задаются с учётом того, что строки содержат конечные символы 0x00. В случае с symlink эти нули не включаются в длину строк и не пишутся в буфер.

4 hours ago, Garl said:

Про удаление нужно логику продумать:

Проводник удаляет только сами ссылки и это правильно.

Share this post


Link to post
Share on other sites
Garl    0
5 hours ago, Guest DRON said:

Да нифига: вызвал DeviceIoControl(FSCTL_GET_REPARSE_POINT) для обоих вариантов и получил в буфере \??\, так что точно бага.

не факт. 

скрипач "\?" не нужен (с)

junction.png

Share this post


Link to post
Share on other sites
Guest DRON   
Guest DRON
8 hours ago, Garl said:

не факт. 

скрипач "\?" не нужен (с)

Факт. Нужен.

 

Image 11.png

Share this post


Link to post
Share on other sites
Garl    0

это fixed обновите ночнушку.  но \? всёравно нету 

Junction возвращает  в lTargetPath  >>> "?\E:\ndn\todo e:\ndn\todo"

откуда брать первый \?

Share this post


Link to post
Share on other sites
Guest DRON   
Guest DRON
13 minutes ago, Garl said:

это fixed обновите ночнушку.  но \? всёравно нету 

Что именно "fixed"?

14 minutes ago, Garl said:

Junction возвращает  в lTargetPath  >>> "?\E:\ndn\todo e:\ndn\todo"

откуда брать первый \?

Из буфера возвращаемого DeviceIoControl, содержимое которого отлично видно на моих скриншотах.

Share this post


Link to post
Share on other sites
Garl    0
21 minutes ago, Guest DRON said:

Что именно "fixed"?

Из буфера возвращаемого DeviceIoControl, содержимое которого отлично видно на моих скриншотах.

пропадание первого символа fixed

ну нету после  DeviceIOControl(LinkHandle, lControlCode, nil, 0, @lReparseBuffer, MAXIMUM_REPARSE_DATABUFFER_SIZE, lBytesReturned, nil) 

в lReparseBuffer.pathBuffer символов \?
 

 

 

sym.png

Share this post


Link to post
Share on other sites
Guest DRON   
Guest DRON
3 minutes ago, Garl said:

ну нету после  DeviceIOControl(LinkHandle, lControlCode, nil, 0, @lReparseBuffer, MAXIMUM_REPARSE_DATABUFFER_SIZE, lBytesReturned, nil) 

в lReparseBuffer.pathBuffer символов \?

Ну так и я о том же: вы неправильно парсите буфер и lReparseBuffer.pathBuffer начинается на четыре байта раньше чем вы думаете.

Share this post


Link to post
Share on other sites
Garl    0
2 hours ago, Guest DRON said:

Ну так и я о том же: вы неправильно парсите буфер и lReparseBuffer.pathBuffer начинается на четыре байта раньше чем вы думаете.

о! уже конструктивнее. мы сейчас о какой версии x32\x64

https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/ns-ntifs-_reparse_data_buffer

ULONG Flags; 

для Symlink И junction то есть то нет! 

не учитывалось это 

 

Спасибо за наводку. дело было в неверной структуре lReparseBuffer. 

залито

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×