Jump to content
Muxe Inc Forums

Garl

Members
 View Profile  See their activity

  • Content count

    757

  • Joined

  • Last visited

Posts posted by Garl

  1. Posted · Report reply

    странно, поиск *.exe по папке (594 найдено)

    nightly_w32.zip: 26 с

    ndn_2_31_5309_bin_w32 - 54c

    v2.31.0407/W32  - 19c

    v2.31.1478 - 15c

    но весь фокус ещё и в кэшировании (повторный поиск происходит быстрее)

     

     

    а ещё можно заметить разницу между Ctrl-H и Ctrl-S  последнее быстрее читает и отображает количество файлов...

    и так же по сравнению со старыми версиями заметно медленнее происходит построение дерева дисков и списка ветви каталога (бранча),

    Видать где то в последнем и закрался "тормознутый" код.

  5. Posted · Report reply

    25 minutes ago, Guest DRON said:

    Не надо их отображать: вызов FindFirstFileName не бесплатен и делать его для всех файлов под курсором нафиг никому не сдалось. Я говорил про показ хардлинков только в диалоге переименования и больше нигде.

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

    в природе есть только FindFirstFileNameW 

    картинка - прототип

    hardlink.png

     

    капец... бывает случай у симлинка есть хардлинк... и как это придумывать отображать.....

  6. Posted · Report reply

    внимание вопрос, вот определили мы что у файла есть 5 ссылок (это одно из 5 имён) как акурано отобразить это на панели информации?

    hardlink.png

    ну в панели можно в переменную "ПУТЬ" запихать (как путь к ссылке) , а вот именно у текущего файла.... не в LFN же пихать?!

  7. Posted · Report reply

    1 hour ago, Guest DRON said:

    Единственное что лично меня беспокоит, это регресс в новых версиях при удалении линков.

    итак: дано:

    1)файл с линком

    2) нажатие F8

    -----------

    что должно произойти?

     

    а) выдать запрос о удалении ссылки  и удалить только ссылку

    б) запрос о удалении файла и удаление сперва ссылки а затем файла (за 1 раз).

    в) ?

     

  8. Posted · Report reply

    >Явно нужна защита от дурака

     Фар так же разрешает баловаться... курс на него или идём своим путём?

    >Так же отсутствуют какие либо сообщения об ошибках при невозможности создать линк любого типа.

    ещё не реализовано же. (будет нам сообщения о ошибках)

  9. Posted · Report reply

    15 minutes ago, Guest DRON said:

    Нет, хардлинки нужно отображать только в диалоге переименования.

    КАК? если у файла 3,4,5 хардлинка(ов)? то есть  2 или 3 разных имени. как его примерно придумать чтобы отобразить?

    можно прикреплять предложения в картинках ...

  13. Posted · Report reply

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

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

  14. Posted · Report reply

    вставка символов в HEX редакторе в х32 версии надо смотреть (в х64  работает)

     

    по хардлинкам:

    Есть ли смысл ковырять и как его вообще придумать отображать? по сути это такой же файл с именем, ссылающийся на данные.

     

    И тут у NDN проблемы: 

    при редактировании ссылки в редакторе, ссылка переименовывается в .BAK, а новый файл получается"чистым"

    такая же история и с исходным файлом....

     

  15. Posted · Report reply

    1 hour ago, Guest WAJIM said:

    В hex-редакторе невозможно вставить символ из таблицы символов. Можно сделать вставку?

    перейдите табом в правйю часть, там вставляется. в левой вводятся только 0-9.. A-F

     

    з.ы.

    научились создавать хардлинки и ссылки (пока без учёта PrintName, может его придётся выкинуть )

  17. Posted · Report reply

    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. 

    залито

  18. Posted · Report reply

    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

  20. Posted · Report reply

    5 hours ago, Guest DRON said:

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

    не факт. 

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

    junction.png

  21. Posted · Report reply

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

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

    з.ы.

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

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

     

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

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

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

     

    как то так...

×