dandv

??? ... NDN implement ... at ndn.muxe.com? so you mean website features??? Sorry, by "fully" i mean *all* features, including really huge strings :-) So I only complained about the strings :-)

Although NDN handles correctly drive/path changing commands from the command line, it doesn't handle them when the active panel is the process list or the TEMP: drive. 1. Go to a directory, say c:\ 2. Type 'cd c:\windows'. Assuming 'c:\windows' exists, NDN will open that directory in the file panel. 3. Make the active panel show the process list of the TEMP: drive. 4. Type 'cd c:\windows'. NDN won't change the panel. BTW, the * and ? indicators should maybe appear in the Alt+F1/F2 lists. Hope this helps, Dan Dascalescu

NDN behaves strangely when editing files with lines longer than 32768 characters: if you press End and move the cursor to the left, it will disappear for a while, even on a very fast machine (2.8GHz). Besides, long lines are wrapped. DNOSP 1.51.10b15 (2004Feb09) handles very long lines perfectly. I've just tested with a 310804-char line (I actually need this feature!) It would be nice if NDN fully implemented the features at ndn.muxe.com: Huge strings support Regular expressions Spreadsheet communications Fully 32 bit version

1. In the extension file, add the entry bug { echo <!:> } 2. Create an archive containing a file "test.bug". 3. Enter the archive, press ENTER on "test.bug" 4. Notice that the echo comand prints two random characters instead of the drive. The drive should reflect the temporary path where the file was extracted in order to be launched. Hope this helps, Dan Dascalescu

1. Options -> Archives -> Current Archiver 2. Ctrl+O, Ctrl+O Notice that the border of the Archiver Setup window suggests it is in Move/Resize mode. You can't edit the textboxes but you can click on buttons. Hope this helps, Dan Dascalescu

Hi Elfy, a bug report will always help. If you have a large file, feel free to e-mail it to me, if you can't upload it somewhere. Aside from that, I haven't used regexps much. Maybe regexes didn't work for you because they contained spaces, which are ignored? (BTW AH, this is a bit strange; are regexps by default "Extended"? I.e. do they ignore spaces? Example: In a file containing "a b xxxxxx", search for "a b" with "Regular expressions" checked. NDN won't find anything. You have to escape the space for NDN to find the string: "a\ b".) Dan

1. Create a file with a filename containing a comma: a,b.txt 2. Alt+F7 for *_* 3. All files containing a comma will be found! Also in DNOSP. Is '_' some sort of macro by any chance!? UPDATE: my thousand separator (Country support) was set to '_', but I changed it to other values, restarted NDN, and the bug was still reproduced. Hope this helps, Dan

Moving/copying to 'RAR:myarchive.rar' should only add 'RAR:something.rar' to the history, not also "myarchive' (that could have the disastruous effect of overwriting the archive to which you've kept adding files!) Hope that helps, Dan

1. Select these two lines and copy them to the Windows clipboard, but take care not to copy the CR/LF at the end of the second line. In other words, you must have in the clipboard some multi-line text NOT ending with CR/LF. For example, you can copy (some of) the tracks from http://www.cdeb.com/cdebnew/celticmyst.html using IE 5 or Opera 7.60. 2. Open an editor (Shif+F4). Options -> Persistent Blocks must be ON. 3. Paste the lines (Ctrl+Insert). The whole text should be selected. 4. Ctrl+PageDown. Notice the last line will be selected incompletely. Hope this helps, Dan Dascalescu

Uhm, this is funny: it's just my point! Note that the second line that you quoted is instead of :-) Anyway, if it doesn't work, try copying the first two tracks from the album at http://www.cdeb.com/cdebnew/celticmyst.html , pasting them to NDN and pressing Ctrl+PageDown.

1. In NDN 2.14.9988 under Windows 2000, select more than one file 2. Alt+E 3. Enter some time, e.g. 1:1:1 and some date, e.g. 1-1-2001. 4. OK. Notice that the files all kept the original timestamps. Hope this helps, Dan Dascalescu

Yep, I noticed it: http://forums.muxe.com/index.php?act=ST&f=24&t=316 I also agree with you that if the files are deleted, they should disappear from the panel. If they are moved, the path should be updated, so the user is able to copy/move them again to another location or view them.

1. Copy a string to the clipboard. 2. Paste it into some file. Notice that the string is highlighted. 3. Alt+Q and paste it at the cursor position. The string won't be highlighted. 4. Bonus bug: if after Alt+Q you press right arrow, the cursor will also move one line up. Hope this helps, Dan Dascalescu

1. When you enter a description to a file, NDN stores in descript.ion/00_index.txt/etc. the short file name. This is WRONG because SFNs are unpredictable and will most likely change when files are copied outside NDN from one place to another. Plus, on burned CDs, SFNs follow some strange rules (the last 2-3 chars of a LFN *always* become ~4, ~6, ~8 etc. even if the first 5-6 chars are not the same). descript.ion handling MUST be changed to LFNs. 2. File descriptions are still handled with old-string code which limits them to 255 characters. This has the nasty effect of truncating manually entered descriptions (typed in descript.ion, not enterd via Alt+Ins) when you copy a file with a length(LFN)+length(description) > 255. Worse, in the resulting descript.ion, the filename will be truncated to the SFN but the description won't benefit from the extra characters: "longfilename.ext" [255-char description here] => longfi~1.ext [237-char description here] Hope this helps, Dan Dascalescu

I've been verifying the variability of CD SFNs since 1999: 1) the SFNs vary depending on the CD burning program used (for example, some sort filename case INsensitively and assign the SNFs with a step of 2: 4, 6, 8 etc. while others sort case sensitively) 2) WORSE, the SFNs depend on OS! Here is an actual example of the same CD read with Win98SE and Win2K: Win98: 4NONBL~6.MP3 4 Non Blondes - What's Up.mp3 [!: analog noise @ EOF] ACEOFB~8.MP3 Ace of Base - Lucky Love.mp3 [!!!: 112 kbps] ACEOF~10.MP3 Ace of Base - Never Gonna Say I'm Sorry.mp3 AQUA-~12.MP3 Aqua - Barbie Girl.mp3 (NICE; perfect earphone quality but pseudo-click 0:04, 0:07, 3:07 on source CD and +1 copy) Win2K:4nonbl~2.mp3 4 Non Blondes - What's Up.mp3 [!: analog noise @ EOF] aceofb~5.mp3 Ace of Base - Lucky Love.mp3 [!!!: 112 kbps] aceofb~8.mp3 Ace of Base - Never Gonna Say I'm Sorry.mp3 aqua-b~b.mp3 Aqua - Barbie Girl.mp3 (NICE; perfect earphone quality but pseudo-click 0:04, 0:07, 3:07 on source CD and +1 copy) In this bug report, as well as in every post from now on, I'll be talking only about the Win32 version. A more general solution, which I do NOT recommend, would be to: 1) when writing descriptions, write the same description for both the LFN and the SFN, just in case someone uses the DOS version of NDN, under DOS, on the same drive. I used this solution myself until 1 year ago when burning CDs: I made a Perl script which computed the SFN on the CD and added to descript.ion the same description from the LFN entry but with the SFN. It worked, but only some times (depending on which burning program was used; I got it working for Nero, but WinOnCD stored SFNs in a different way!). I stopped adding SFN descriptions when I realized that Win2K assigned the SFNs in a totally different way. 2) when reading descriptions, if more than one description is found for a given file, pick the one from the longest filename. The standard for descriptions is pretty clear: <filename|"filename"> (space|Tab)+ <description> <EOLN> This standard is followed by NDOS (descript.ion), WhereIsIt (the leading CD cataloguing tool), DNOSP, FAR etc. Agree, here's a sample description I use: "The Time Machine.avi" 66/100; 1:30:32/1:32:57; 640x272 DivX3 LowMotion @ 23.976 fps & var. keyframe freq., 899.8 kbit/s, Qf: 0.216 bits/pixel; 48kHz Joint Stereo incorrectly formatted (VDub complains), synchronized and normalized 141kbps VBR MP3; perfect underlying file & loudspeakers/video quality

NDN 2.14.1985 (actually 9985), 2004-Nov-17, eng, Win2K: In the file manager, Shift+Alt+Insert brings the Edit Description dialog. Other keyboard combinations might be messed up, too. Hope this helps, Dan Dascalescu.

NDN2.14.1985 (i.e. 9985) Create the following PCREbug.txt file: delta alphaxxbeta alphaxxbetayyteta text alphaxxbeta gama 1. Search (F7), regular expression ON, for "text". Notice that the first search (i.e. immediately after you press Enter in the Search dialog, doesn't do anything. Press Ctrl+L to actually find "text". 2. Search for a bit of Garl's funky regular expression, ^[^y]+$ This should match any line not containing the character 'y'. Why doesn't this match anything? 3. Search for xx[^y]+" This should repeatedly find any "xx" followed by the longest string not containing "y". Why does Ctrl+L keep highlighting the same "alphaxxbeta" and then some nonexistent spaces instead of highlighting the second "alphaxxbeta" then stopping? 4. Search for xx[^y]+$ This should find the same as above, but clearly until the end of the line (no nonexistent spaces). Why does it only find the second "alphaxxbeta"? I hope this is not a PCRE bug :-) Dan Dascalescu

I couldn't come up with a precise way to reproduce this bug, but since it shows more often than not, just play with NDN and you'll see: 1. Edit a file in NDN 2. Select several lines. 3. Ctrl+Insert 4. Go to a windows application such as Notepad, and paste. If you do get the lines, go back to step 2 in the same file and select some other lines. After at most 5 tries, you'll see that pasting in the Windows application won't bring anything from the clipboard. 5. When you get to that state, you'll see that you can only copy to the Windows clipboard very short texts (sometimes not longer than 3 characters). Please let me know if you managed to reproduce this bug, Dan Dascalescu

Hi Garl, How in the world did you come up with this regexp ?! Did you actually test it ?! To set things straight: 1. The regexp you suggested is pure crap, both in theory and practice. NDN uses PCRE, and according to the Perl 5 regular expression syntax (http://www.perldoc.com/perl5.8.0/pod/perlre.html), what you wrote is crap because: [^yy] is a negated character class, so one 'y' is enough: [^y] [^y]+ will prevent things like "yzxx" from matching, which, according to the asker, SHOULD match same goes for the second [^yy] oddity due to some weird bug in NDN, this regexp doesn't work; I reported the bug at http://forums.muxe.com/index.php?act=ST&f=24&t=329 2. The correct regexp is ((?!yy).)*xx((?!yy).)* which can successfully be tested agains the sample file I posted at http://forums.muxe.com/index.php?act=ST&f=24&t=329 3. Read perlre :-) 4. For some heavy-weight regexp usage, visit my Proxmail page (URL in the signature). Hope this helps Basil/2. Dan Dascalescu

1. View a file, e.g. NDN.EXE 2. Press F4 to enter "Dump Mode" -- the one like: 0006c080: CYGAWF@WE@UE@UE?TE?TD@UD@UE@TE@UEAUFAVFBVGBWGCXHCXIDZJEZKFZKG[LH 0006c0c0: \MI]OJ]PK^PL`RNbUPgZVqaK 0006c100: 0006c140:             ¼P    ¿        ─ì 0006c180: ¼ì       ╤ì ╝ì           ▄ì Ωì ·ì Â Â Ä 0006c1c0:   KERNEL32.DLL user32.dll  LoadLibraryA  GetProcAddress  Exit 3. Press Ctrl+PageDown to get to the end of the dump 4. Press PageUp and notice that it doesn't scroll up one page. Instead, it jumps to the beginning of the dump. Hope this helps, Dan Dascalescu

This is the second time I got this error, and the conditions to reproduce were the same. However, I can't sistematically reproduce it, so please check the NDN.ERR at http://home.arcor.de/dandv/MovingManyFiles.zip Steps to attempt to reproduce: 1. In a directory, have around 10,000 .txt files. 2. Select them all, and rename them to something else (I renamed *.txt to Efr*.cnm) 3. After renaming some of the files, NDN might crash with the error in the ZIP file at the URL above. Note that the FILE filed of the error is messed up. I'm sorry I can't provide precise info on how to reproduce this one, Dan

It sure is. What if the user moves the files to another drive, so they must be copied, but NDN copies the last file (before it crashes) only partially? Just an example. I reproduced it once with only 1000 files. To create the files, you can simply run this from the command line: for /L %i in (1, 1, 10000) do echo "File %i" > "file%i.txt"

I encountered this bug when I tried to copy the error message from the NDN.ERR at http://home.arcor.de/dandv/MovingManyFiles.zip . DNOSP can successfully copy the entire error, but NDN will truncate it after the first null ($0) byte in the "FILE:" field. Hope this helps, Dan Dascalescu

If you Alt+F7 for 'temp', NDN will automatically search for 'temp*'. This is fine. However, NDN also has a feature for searching for more than one file mask: the masks must be separated by a semicolon. But, if you search for 'something;temp', NDN won't add a '*' to either 'something' or 'temp'. To be consistent, NDN should process each of the filemasks and search for 'something*;temp*'. Hope this helps, Dan Dascalescu

The '^' (line start) regexp metacharacter only works in the editor, not in the viewer (and hence, not in File Find by text). 1. Create a file bug.txt containing just 'bug' 2. Edit the file, search for '^bug' with Regular expressions enabled. NDN will find the string. 3. View the file, perform the same search. NDN won't find the string. 4. Alt+F7 for the file with the same 'Text to find': '^bug'. No results. Hope this helps, Dan Dascalescu