GPFault

Hi. I'm back to this forum after 13 (!) years of inactivity. I'm not a DN user anymore (due to becoming a linux user, and ndn on linux wasn't stable 13 years ago), however, I still think that DN UI is tuned better then any other file manager, so I'm still inetersted in the "NDN on Linux" future. Recently I found information about somebody investing thier time into porting DN variant called DNOSP to linux - https://www.linux.org.ru/news/opensource/15971481 (text is in russian) The project link is https://www.linux.org.ru/news/opensource/15971481 The project developer said that he treated NDN as closed source-project. But technically, I think NDN has more mature linux support that the project I linked above, and it's a pity that human developer resources related to Dos Navigator was spent to less advanced variant (DNOSP) instead of more advanced NDN. As far as I know 13 years ago the source code was available to "anybody who really want to edit & contribute". I asked for it, ans Stefan provides me the archive (I've lost it many years ago). In modern days, such semi-private code development sometimes leads to waste of human resources (due to work on another variant as a I pointed above). Do nowdays ndn developers have any objections to publishing the entire source code? Are there any formal licencing issues? If the only thing that stops you from publising sources are technical - the lack of time or "dont want to investigate how to create git history" etc - I'd be glad to help in publishing it. For example: you choose the public hosting platform (gitlab, github, sourceforge or choose any other) send me the sources of several versions as archives and I create organization account on the hosting platform convert the archives to git history, publish sources on that hosting, and add your account on the platform as an administrator of that project. My actual e-mail is galkin.vv@remove.anti.spam.org@yandex.ru (English or Russian).

Дальше будет много букв - поэтому общая суть и вопросы - сначала: Писал ли кто-то в последнее время письмо CandyMan с прямым вопросом о разрешении на открытие? Если нет, то на мой взгляд уместно (и я готов) написать ему по английски что-то в духе - "если вы откроете исходники, то у вас вероятно появятся новые... пользователи, как минимум я". Garl, есть ли принципиальные возражения против написания такого письма? Или это настолько глупо/странно/абсурдно, что и писать не стоит? Если CandyMan даст добро - будет ли согласие со стороны Garl? Теперь подробнее. Я возможно покажусь путаным/навязчивым/эгоистичным, но попробую донести точку зрения немного с другой стороны. Пользовался NDN 13 лет назад, и помню что он удобен. Сейчас я активно пользуюсь linux, в том числе во многих ситуациях терминалом/консолью. MC - не перевариваю, крайне малофункционален. Но NDN я уже давно не "щупал". Какая по факту причина? Без исходников присутствует абсолютно полная неуверенность в завтрашнем дне. Приучишься пользоваться, привыкнешь, потом что-нибудь поменяется в ОС что надо будет пересобрать с минорным изменением, а к этому времени авторы утратят интерес к проекту - и в результате ни исходников, ни улучшений от авторов. Открытость исходников - это по крайней мере гарантия того что получается избежать глупой ситуации "нужно минорное изменение, но его сделать некому, исходники утрачены или остались только у полностью незаинтересованных лиц". Такие заморочки наверное только у разработчиков) У тех кто сам "в случае чего" пересобрать не сможет в любом случае - таких заморочек нет. Исходя из написанного выше - что я могу сказать насчёт пользы от открытия исходников? Оценивая статистику я наверное что-то контрибьючу только в ~0.1-1% от проектов которыми я пользуюсь. Так что говоря честно - в случае открытия исходников - шанс что я что-то залью - статистически мал) Так что же произойдёт от открытия? Весьма вероятно что я попробую пользоваться ndn на linux, в тех задачах, которые у меня возникают. В случае успеха- может покажу паре знакомых. Понимаю, что всё звучит очень глупо, но получается что "открытие исходников принесёт проекту ndn некоторое количество пользователей, как минимум меня" )) Почему я например вообще не заинтересовался dn2l, даже как пользователь? Потому что по описанию мне показалось что для пользователя он гораздо менее доделан, чем ndn. Осознанно выбирать менее удобный инструмент когда есть более удобный ndn - ощущается странной идеей. Да и с проектом которым ещё нельзя пользоваться, я например связываться не готов. Большинство моих вкладов - это доработки уже вполне активно испльзуемых проектов. Более того, идея дописывать что-то в dn2l сильно демотивируется... перспективой что ndn откроют, и написанное для dn2l в этот момент станет или неактуальным (станет жалко потраченного времени) или придётся делать сложный и мучительный merge. В общем, совсем не факт что открытие принесёт хоть одного контрибьютера, это так. И если разработка делается только "для души под свои нужды" - то открытие вам ничего и не даст. А если она делается "для души для себя И для потенциальных пользователей" - то открытие исходников - это способ их привлечь) По крайней мере тех кто в подобных продуктах выбирает преимущественно открытые решения.

Hi. There is a problem in v2.30.6778/RUS (06-07-2007) WIN32, os - win2k3 (and as far I know in most previous versions in other operating systems): When I try to move folder within single drive (with F6) - NDN does recursive renaming. But it`s too slow if there is a lot of files in folder (>1000). Why single rename of the folder is not used? It`s a lot faster. If single renaming fails for some reason (locked files etc) - yes, in such case recurive renaming may be good idea, but not in general case, i think. Far, for exaple use single renaming and it works fine. In non-Windows OS's doing this with a single renaming is also possible. Thanks.

The problen I described in first post looks to be another problem - it applies only to F6 (renaming with alt+F6 works correctly) and it applies to directories and not files. Maybe I hadn`t described it clearly in first post. I have folder named BigFolder containing 1000 files. It is located in C:\FirstDir I want to move it to another place in drive C: - to the C:\SecondDir C:\FirstDir is in one panel, C:\SecondDir is in other one. I put cursor to the BigFolder and press F6, Enter. What happens: -NDN creates folder BigFolder in C:\SecondDir -NDN does 1000 renaming operations - it renames C:\FirstDir\BigFolder\file1 to C:\SecondDir\BigFolder\file1 and makes such operations for each of 1000 files. -NDN removes empty C:\FirstDir\BigFolder aybe even 1000 files. But for directory with complex subdirectory structure and a dozen thousands files in it the operations maybe really slow (a few minutes) Allmost all other filemanagers do this operaion instantly - they use only one OS filesystem call - renaming C:\FirstDir\BigFolder to C:\SecondDir\BigFolder and does not any recursion. So, the problem in whatsnew/todo looks to me as another one. If it`s really the same, I'm sorry. About recreation - I have this problem with both: -2.30.6778 in windows with custom settings on NTFS -old ndn v4000 in dos with default settings on FAT so it`s really strange if you hadn`t it

Hi! There is an error with deletion of directories with long names in NDN/W32. Unfortunately, I can`t say what is the first version where it appears, but it is some from last 0.75 year, maybe version where background deletion were introduced. Steps to reproduce bug: On LFN-only drive cretate a directory with long name like 12345678901234567890 Try to delete it - the following error occured ╔══════════ Erase ══════════╗ ║ ║ ║ Erasing the directory ║ ║ 123456789012 ║ ║ subdirs: 1 ║ ║ files: 0 ║ ║ Total: 1 ║ ║ ║ ║ Stop ▄ ║ ║ ▀▀▀▀▀▀▀▀▀▀ ║ ╚════════════ 0 ════════════╝ ╔═[■]════════════ Error ═════════════════╗ ║ ║ ║ Could not delete the directory ║ ║ D:\123456789012 ║ ║ ║ ║ OK ▄ ║ ║ ▀▀▀▀▀▀▀▀ ║ ╚════════════════════════════════════════╝ Looks like name is truncated to 8.3 Note: this error occures only on NTFS drives with disabled short names, not in regular drives Files with long names are deleted properly. Subdirectories with long names are deleted properly too, for example: I have folder d:\short\12345678901234567890 I go to d:\short\ , try to delete 12345678901234567890 - get error lioke above I go to d:\ , try to delete short - it is deleted correctly NDN: Version v2.30.3829/ENG (25-12-2006) WIN32 (W9x/WinNT) with all settings default OS: Win2003 SP1

It`s feature: here: http://forums.muxe.com/index.php?showtopic=766 ... [+] concurrent/background Copy/Delete is possible ... ([+] ôîíîâîå Êîïèðîâà íèå/Óäà ëåíèå)

You have chosen correct forum, so, it seems nobody knows how to change drive letters in linux version of ndn

Hi, alouette I haven`t any problems with FF1.5.0.7 (win32) So, it seem`s to be bug in your FF settings (though i`m not sure). Maybe it`s AdBlock( http://forums.muxe.com/index.php?showtopic...st=0&p=1892 ) Try to disable it. Please let us know if this helps. 2WebMaster(Stefan or somebody else(?)): if alouette confirm download link to be cut out by adblock it may be a good idea to change link. This seems to be common problem.

Looks like http cache is misconfigured somewhere (in ndn.muxe.com, your provider or some proxy, or in your browser) Archive size for last windows version (2.30.0024) is 1 084 839 You may try to download it here: http://gpfault.smtp.ru/_w32.rar (link is NOT permanent, I delete it next week)

Hi, coucou maybe this topic helps you http://forums.muxe.com/index.php?s=&sh...post&p=1892

Bug is not new, but only now I found when it appears NDN v2.30.0000/W32, all settings are default To reproduce: - Open/create in editor file with >=2 lines - go to first line - press End - press right (->) - press backspace Happened: second line is concatenated with the first Behaviour of many other text editors: cursor moved one character left Really, I don`t know which behaviour is better, and I`m not sure is it bug or wanted behaviour. What is it?

Hi, FoxCrunch The screen looks like you are running NDN in utf8 terminal, but maybe problem is more comlicated, because it looks even more buggy than i see in UTF8 linux console... Unfortunately NDN does not support locales and multibyte encodings, like utf8... So, the only thing that can help, is changing terminal options. You may try to put your terminal in some single-byte encoding, (like koi8r), or try to use another terminal like putty

OK. Sorry, if my previous post was too critical, I need to think on much of it again. int 80 is absolutely non-stndartized and really changes over years, while LINUX C API is fixed and never change. [very imho] the only non-ugly way to communicate with Linux kernel is using statically or dynamically linked libc. using int 80 intead of libc is like using ntdll.dll instead of kernel32.dll I see no way to change this situation mostly because of vp. [/very imho] Sorry, i didn`t look in sockets before your post. If there is really dynamic linking that works - it`s good but ldd says $ldd ndn not a dynamic executable (???) and pe2elf is really strange tool... such background processing in DOS is very good, but in modern multithreading OS background processing without inkernel threads is slow and imho ugly. when i say "UTF-8 support" i mean all strings inside NDN to be in UTF-8 (which is variable bytes-in-character encoding). Variable bytes-in-character lead to breaking most of TVision. So, speaking really, it is impossible. Converting to/from UTF-8 in interface with terminal and/or filesystem imho is ugly and lead to lot of bugs. here is the meaning of part i agree (not strict translation, but meaning is mostly the same): IMHO ndn developers should pay attention mostly to linux not to Windows. There are many file managers for Windows that are good. NDN is as good as Far, but it is nearly impossible to create a filemanager much better than Far. But on Linux platform there is no good console filemanagers and NDN have a chance to became the Main console fm for linux.

I 100% agree VP support for DOS/windows/OS2(?) is well enough, but Linux, hm.... IMHO vp linux support is extremly ugly and incomplete... Yes, the current linux version is not bad, but I think, that fully usable linux version can`t be created with vp. The main reason is: vp seem not support dynamic linking for linux, and many standard libs functions are reimplemented at kernel level (with int 80) So if full linux support is not one of the main lines of development vp is ok, but in other case vp isn`t. (all text after here is only IMHO) Also I 100% agree with this post There is many file managers for Windows. Generally, I think, Far is not much better than NDN, NDN is not much better than Far. For me NDN is a little better than Far, so I use NDN. If there wasn`t be NDN i had to use far in such case, it wouldn`t be a big problem. On Linux i have no good altenatives(mc isn`t), so i need use NDN, but now it has too much small bugs. Most of them are reasoned by the fact that firstly DN was old dos program and now it emulate DOS api on all OSs (not everywhere, but in many parts of code). Some things like attributes can be fixed, but some modern(ok, they were modern in 1992(?) when dn was born) technologies such as multithreading(background copy, calculation background completions of filenames in background), UTF-8 need rewriting of >>50% code. So the questions are: 2Stefan: Is good linux support among of the 2-3 main lines of development? 2All: Is here anybody except me who wants Linux version more than Windows one? P.S. I am NOT a big linux fan (now :) )

Ãòî íå îøèáêà NDN. Ãòî îøèáêà windows. Ìîæíî òðà êòîâà òü å¸ êà ê îøèáêó â âåêòîðíûõ øðèôòà õ, èëè êà ê îøèáêó â êîíâåðòà öèè CP866<->unicode. Åñëè èñïîëüçóåòñÿ Lucida Console, òî ñà ìûé ïðîñòîé ñïîñîá èñïðà âëåíèÿ - ïîñòà âèòü ïîïà ò÷åííóþ âåðñèþ îòñþäà Lucida Console Patched. Êðîìå òîãî, äëÿ íåêîòîðûõ âåðñèé windows ìîãóò âîçíèêà òü à ðòåôà êòû ìåæäó ñèìâîëà ìè äëÿ âåêòîðíûõ øðèôòîâ îïðåäåë¸ííûõ ðà çìåðîâ, ýòî òîæå ãëþê âèíäû. It isn`t NDN bug.

Hi! In whatsnew.txt for 2.15.8835 there is [-] W32 !: sometimes returned crap (Dandv) [A] -> lfn.lGetShortFileName had no error handling (usermenu.MakeString) Unfortunately, it is not completely fixed For names longer then 12 symbols on NTFS volumes with disabled short names !: macro return garbage. (NDN 2.15.9289 w32, tested in win2003 SP1 and winXP SP1) To reproduce: Disable 8.3 name creation on NTFS (set HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation to 1) <maybe you need to reboot here> Create file with name longer than 12 symbols try to expand !: macro for such file Note: Bug do not appear for files with names shorter than 13 symbols, even name isn`t 8.3 (For example 123456789012 - OK, 12345.678901 - OK), but one symbol longer and garbage appear instead of disk name. Length of garbage is correct (2 chars), and it never lead to access violation(so it seems not to be absolutely random address). The garbage is changing time to time, but not every time.

E: is NTFS with disabled short names, C: is FAT For file E:\WIN2K3\TEMP\longfoldername\ThisIsLongName.ThisIsLongExtension i get the following: "!:" is "0+" "!/" is "\WIN2K3\TEMP\longfoldername" "!\" is "\WIN2K3\TEMP\longfoldername\" "!" is "ThisIsLongName" ".!" is ".ThisIsLongExtension" "!~/" is "" "!~\" is "" "~!" is "0+" ".!~" is "" For file C:\longfoldername\ThisIsLongName.ThisIsLongExtension i get the following: "!:" is "C:" "!/" is "\longfoldername" "!\" is "\longfoldername\" "!" is "ThisIsLongName" ".!" is ".ThisIsLongExtension" "!~/" is "\LONGFO~1" "!~\" is "\LONGFO~1\" "~!" is "thisis~1" ".!~" is ".thi" For file E:\WIN2K3\TEMP\longfoldername\shrtname.ext i get the following: "!:" is "E:" "!/" is "\WIN2K3\TEMP\longfoldername" "!\" is "\WIN2K3\TEMP\longfoldername\" "!" is "shrtname" ".!" is ".ext" "!~/" is "\WIN2K3\TEMP\longfoldername" "!~\" is "\WIN2K3\TEMP\longfoldername\" "~!" is "shrtname" ".!~" is ".ext" For file C:\longfoldername\shrtname.ext i get the following: "!:" is "C:" "!/" is "\longfoldername" "!\" is "\longfoldername\" "!" is "shrtname" ".!" is ".ext" "!~/" is "\LONGFO~1" "!~\" is "\LONGFO~1\" "~!" is "shrtname" ".!~" is ".ext" So in 2.15.9289 garbage seems to be returned only for !: and ~! Different bugs with !~/,!~\,~!,.!~ on E: seems to be ok, because short names REALLY does not exist (programs that operate with short names (for example ndn d32 with [X] Don`t use LFN) don`t see presence of such file at all). So wrong expansion of *~* macroses is not bug, because it can`t be fixed :)

1. In 2.15.8835 selecing unsorted order in find panel lead to crash(i`m not sure but in some older versions it sorted by path correctly) 2. some strange behaviour in editor(tested with unlimit uninindent on, smart (un)?indent off, SHIFT-TAB for window switch off, tab move blocks on) Create 2-line file: Â aaaa aaaa (There is one leading space in first line) select all press tab all lines are indented with 3 spaces (because i have tab set to 4) Now add a leading space to each line(you get tabsize+1 spaces in first line, tabsize in second) select all press tab (indent with 3) press shift+tab(unindent with 4) So we have tab, shift+tab is not equivalent to nooperation Is this really wanted behaviour in case of blocks(in one line case it`s ok, but with block we get all block indent size depending on 1st line)? maybe use always tabsize for indent of block? (it`s only an idea to think; really i hadn`t decided to myself which behaviour is better)

Hi. NDN 2.15.8835 W32,LNX When NDN can`t determine line type (file has only one line without line break after it) it set it to CrLf, regardless of EditorDefaults.LineDivisor option. To reproduce: - set EditorDefaults.LineDivisor to Lf - create new file with one line. It`s OK it has Lf in bottom border. Save it. Close it. - Open again - now it has CrLf. EditorDefaults.LineDivisor option should be used as default value here. This bug may lead to creating shell scripts in linux with wrong line separator. Most of such scripts doesn`t work correctly - but visually they are correct...

I have the same problem with some anti-advertisement software. The reason is that the link address is (for windows) ndn.muxe.com/fclick/fclick.php?ad=2 and such software think that this is an adv link because of words "click" and "ad" and cut it off Alternative links: Windows: http://ndn.muxe.com/archives/_w32.rar Linux: http://ndn.muxe.com/archives/_lnx.rar Dos: http://ndn.muxe.com/archives/_d32.rar

Hi. NDN file operations doesn`t support symbolic links: The worst problem, i think is deletion: NDN treates symbolic links in linux as folders and tries to delete all it content. This may be VERY dangerous. Imagine that you want to delete folder with a lot of content. And deep in it there is a symlink to another place you don`t want to delete.(f.ex. many projects may have symlink to one library) NDN delete ALL content under the link. But it can`t delete the link(because link should be deleted with file api not the dir api in linux). This behaviour is opposite to other linux tools. They all only delete the link(and this seems correct to me). The same problems are in copy operations but they are not such dangerous. Also there are same problems with windows NT symlinks(but fortunately they are not such popular as linux symlinks). So, imho, problem with deletion is really BUG (at least in lnx) and not the lack of feature.

Ãîõîæå íà ýôôåêò îò çà ïóñêà íåêîòîðûõ dos-ïðèëîæåíèé ïîä NT â ïîëíîýêðà ííîì ðåæèìå Ìåòîä 1: Ê ndn ïðèëà ãà åòñÿ äðà éâåð noblink.com (â òîé æå ïà ïêå, ÷òî è ndn.exe) Ñîçäà ¸ì bat-ôà éë ñëåäóþùåãî âèäà : @"E:\program files\ndn\noblink.com" @"E:\program files\ndn\ndn.exe" è çà ïóñêà åì ndn ÷åðåç íåãî Ìåòîä 2: ÃÃ¥ èñïîëüçîâà òü ïîëíîýêðà ííûé ðåæèì À ÷òîá îêíî áûëî âî âåñü ýêðà í: Shift+F12, âûáðà òü ïîñëåäíèé ðåæèì Åñëè íå ïîìîæåò òî ìîæíî ïîïîäðîáíåå: Ìîæåò *.prg - ýòî âñ¸-òà êè dos? ýôôåêò ïðîÿâëÿåòñûÿ òîëüêî ÷åðåç ìåíþ èëè ïðè çà ïóñêå èç ïà íåëåé/êîì. ñòðîêè òîæå?

win32 - äîñ ðóñèôèêà òîð íå ïðèêðóòèòü... ïîñëåäíèè âåðñèè òóò:http://ndn.muxe.com/beta.php Îíè betû òîëüêî ïî íà çâà íèþ - ïîñëåäíÿÿ ïîñòà áèëüíåé 2.15.4000 áóäåò NDN is FreeWare

Åñëè D32: ïðîâåðÿòü ðà áîòîñïîñîáíîñòü ïåðåêëþ÷åíèÿ íà äî íå â cmd.exe à â command.com Ãî ñâîåìó îïûòó ìîãó ñêà çà òü, ÷òî çà ñòà âèòü ðà áîòà òü dos-ðóñèôèêà òîð äëÿ dos-ïðîãðà ìì(â ò.÷. dos32 ndn) ïîä NT-ñèñòåìà ìè äîâîëüíî ïðîáëåìà òè÷íî, õîòÿ ñ íåêîòîðûìè ðóñèôèêà òîðà ìè âîçìîæíî. (êîïà òü autoexec.nt) Îäíà êî dos32-âåðñèÿ NDN ïîä nt ðà áîòà åò íà ïîðÿäîê õóæå ÷åì win32-âåðñèÿ. Âîîáùå âðÿä ëè ýòî êà ê-òî ñâÿçÿà íî ñ NDN I don`t think it`s NDN bug.

Hi! Selection in hex text doesn`t use horizontal scroll position To reproduce: Alt-F7 Text to find: 12345678901234567890 home right right(cursor under 3) Shift-right until scrolling begin - you see 2 first entries in hex are never selected I`d experimented with resizing search dialogs and found following: If input is quite long hex input is shown as in hex view mode - with | and symbols after it example from veiwer: Èñêà òü òåêñò abcdefghijklmnopqrstuvwx Ãex 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 | cdefghijklmnopqr Also it seems strange to me that in .dnr there are hsFindText and hsViewFind styles.(maybe i hadn`t noticed somthing...) AH, you said you want some LNX bugs :) Here are some bugs i had, but i`m afraid i can`t provide enough info to reproduce. 1. Crash with Ctrl-O under X(gnome-terminal,rxvt,xterm). Esc work fine - screen is showed. In fullscreen in the same system there is no crash. (but there is garbage - terminal is dumb (mc show nothing on Ctrl-O so it`s not bug)). (sorry for old 7555 version) NDN.ERR: VER :Necromancer's Dos Navigator LINUX mode ADD :v2.15.7555 (24-02-2006) ERR :C8h (200) ADDR:0049c7a0 MSG :Division by zero OSD :32 (88x39) SYS :Linux FILE:/windows/F/ndn/source/usermenu.pas(156) MEM :F7F93BF07D2D8B0D041C52008B85F8FD (at CS:IP) CS :0023 DS :002B SS :002B SP :D220 MEMm:02f16000 MEMa:02f28bd0 in .err file all screen except menu and statusline is filled with 0x0E (Mandrake 8.?) 2. Problems with cmdline: on some systems nothing happen(Gentoo 2006 livecd) on execution, on some other(Mandrake 8.?)new started programs has stdin assigned to smth other than terminal - so they can`t read input(all except man). 3. Alt alone never work as start search even if pressing it switches statusline correctly - so NDN get it. If there is no solution for this problem even in case when NDN get it, a hot key for search will be useful.(MC use Ctrl-S) 4. cd command without argument should go to user`s $home. (like cd ~). imho it is *nix standard. Do you use ncurses lib for console output? It may be solution for some output problems. Now ndn on starting in console do somthing really awful with charset. in some cases i get latin letters instead of pseudographic lines. In Mandrake 8.? i use command "charset G1 user" when some program (not NDN) damages terminal charset. After it all programs with pseudographic work fine, but ndn doesn`t. ndn work wrong even there wasn`t damage before "charset G1 user" command - so it`s NDN bug. (i keep silent about problems with russian) P.S. Problems 2 (and 3) make NDN completly unusable for me on some systems as file manager(but i use it as editor :))