Hi Tom,
I think Zbigniew should state which version of the FreeDOS kernel he is using, but because you have asked me so *cough* politely, I hereby present some test results for a FreeDOS FAT32 enabled Watcom C compiled Kernel 2038 (2009-05-16) in DOSEMU2... 1. switch to a diskimage-based drive, to avoid changing results by accidentally probing the DOSEMU2 virtuala filesystem instead. In my case, this was D:\ which is a FAT12 drive (as whichfat d: can confirm, just to make sure) 2. make sure that a file D:\TEMP\textfile.txt exists 3. in the D:\TEMP\ directory, run DEBUG... -acs:100 08C3:0100 jmp 116 08C3:0102 db "textfile.txtgarbage",0 08C3:0116 mov ax,3d00 08C3:0119 mov dx,102 08C3:011C int 21 08C3:011E int 20 -gcs:11e AX=0005 BX=0000 CX=0000 DX=0102 SP=FFFE BP=0000 SI=0000 DI=0000 DS=08C3 ES=08C3 SS=08C3 CS=08C3 IP=011E NV UP DI PL NZ NA PO NC 08C3:011E CD20 INT 20 (it opened textfile.txt) -rip IP 011E :100 -acs:102 08C3:0102 db "textfile.txt",0 08C3:010F -gcs:11e AX=0006 BX=0000 CX=0000 DX=0102 SP=FFFE BP=0000 SI=0000 DI=0000 DS=08C3 ES=08C3 SS=08C3 CS=08C3 IP=011E NV UP DI PL NZ NA PO NC 08C3:011E CD20 INT 20 (it opened textfile.txt again) -rip IP 011E :100 -acs:102 08C3:0102 db "textfiletxt",0 08C3:010E -gcs:11e AX=0002 BX=0000 CX=0000 DX=0102 SP=FFFE BP=0000 SI=0000 DI=0000 DS=08C3 ES=08C3 SS=08C3 CS=08C3 IP=011E NV UP DI PL NZ NA PO CY 08C3:011E CD20 INT 20 (it failed to open any file) -rip IP 011E :100 -acs:102 08C3:0102 db "textfile.yy.txt",0 08C3:0112 -gcs:11e AX=0002 BX=0000 CX=0000 DX=0102 SP=FFFE BP=0000 SI=0000 DI=0000 DS=08C3 ES=08C3 SS=08C3 CS=08C3 IP=011E NV UP DI PL NZ NA PO CY 08C3:011E CD20 INT 20 (it failed to open any file) -rip IP 011E :100 -acs:102 08C3:0102 db "textfilegarbage.txt",0 08C3:0112 -gcs:11e AX=0007 BX=0000 CX=0000 DX=0102 SP=FFFE BP=0000 SI=0000 DI=0000 DS=08C3 ES=08C3 SS=08C3 CS=08C3 IP=011E NV UP DI PL NZ NA PO NC 08C3:011E CD20 INT 20 (it opened textfile.txt again) -rip IP 011E :100 -acs:102 08C3:0102 db "textfilegar.txtbage",0 08C3:0116 -gcs:11e AX=0008 BX=0000 CX=0000 DX=0102 SP=FFFE BP=0000 SI=0000 DI=0000 DS=08C3 ES=08C3 SS=08C3 CS=08C3 IP=011E NV UP DI PL NZ NA PO NC 08C3:011E CD20 INT 20 (it opened textfile.txt again) As you can see, THIS kernel version is NOT affected by the predicted "textfile.yy.txt" or "textfiletxt" issue, but additional text after the first 8 characters before AND after the first 3 characters after the "." is BOTH silently ignored, exactly as noticed by Zbigniew. >> In short, when you open "textfile.txtgarbage", the garbage >> is suspiciously silently ignored and "textfile.txt" opens. > DOES THIS DIFFER FROM MSDOS BEHAVIOUR? The reply by Steve suggests that it does not, but it is not documented in RBIL either. I do not have MS DOS installed, so no comment from ME about "what would Microsoft do?". > should be trivial to verify. > >> So it SHOULD FAIL when the filename (without the directory >> name) does not fit into 8+3 characters. But it fails to fail! > DOES THIS DIFFER FROM MSDOS BEHAVIOUR? See above. > it's not what you or ZB think it should behave like. > it's about compatibiliy. How about documenting it as INTENDED way to behave exactly as some undocumented aspect of MS DOS, for example in FreeDOS source code, if that is what you imply here? That would be better than just shouting at us. >> I believe > > 'I believe' simply has no place here. You are easyly capable to pro or > disprove of this. Unless you are a complete moron. I must be a moron then for being unable to telepathically extract YOUR knowledge about undocumented MS DOS from either your brain or the missing comments in our source code :-p >> you could tell function 3d to open "textfiletxt" and it would in reality >> open "textfile.txt" because the 11 character basename overflows >> into the memory reserved for max 3 bytes of file name extension. > DOES THIS DIFFER FROM MSDOS? DO I HAVE MSDOS? >> What is worse is that you will probably crash DOS > should be easy to show us a function to crash FreeDOS (or MSDOS). I am not sufficiently upset to acquire exactly the kernel versions discussed in my previous mail to check whether UNSTABLE can crash, but as I have already predicted in my previous mail, HEAD is not expected to crash: It is ONLY expected to silently truncate parts of the file names which: 1. TK Chia has explained to be a desired behavior for some sort of poor man's long file name support while no LFN drivers are loaded 2. Steve Nickolas has implied to be bug-bug compatibility with MS DOS 3. Has motivated you to rant and rave instead of doing anything useful > otherwise just shut up. Maybe not. > thanks Regards, Eric _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
