I want to make a directory on the root to be stored as 8.3 filename, not Long Filename. Is my directory name limited to 8 characters or 11 characters?
EDIT: Also, if in Windows XP, I create a file which conforms to 8.3 standard, will Windows XP actually store it as "legacy" 8.3 or will it store it with LFN for the hell of it?
Hi Aero,
I haven't read much on FAT32 but AFAIk, 8.3 is a thing of FAT12(Not sure about FAT16). I THINK they are stored as LFN itself. I will check out and let you know.
Thomas :U
I think this is what happens: all LFN records actually contain an 8.3 record at the end, so it doesn't matter (I can ignore the LFN records and just read the 8.3 one). I just wanted to verify this with someone else, though.
Hi,
I just now read the MS Docs. They say that the FAT32 dir entries contain space for 8.3 bytes only . But for LFN, a special bit combo is set in the attributes which causes it to go through other entries in order to get the whole file name
Thomas :U
I don't know about Windows XP, but for previous versions of Windows the system would generate a short name for any non-8.3 name. For short names the 8.3 applies to directories as well as files. AFAIK if you specify an 8.3 name it will be stored as an 8.3 name. For more information you could try a 16-bit DOS app that calls the LFN version of the FindFirstFile function (Interrupt 21h, function 714Eh). See Ralf Brown's Interrupt List for information on the LFN functions, and the FindData structure used by the FindFirstFile function.
An HTML version is here:
http://www.ctyme.com/rbrown.htm
And the download version here:
http://www-2.cs.cmu.edu/~ralf/files.html
I don't know of any way you can reasonably view the actual directory entries under Windows XP (even from a DOS app).
Also, MS-DOS is not case sensitive, yet when I say dir it gives the case in which I typed it in in the first place. Example: I make a file called AbC, and it shows up as AbC, but I create a file called abc and it shows up as abc. Does this mean, when reading the FAT32 filesystem, that I have to be case-sensitive with filenames?
Hi,
FAT32 is not case-sensitive. |Its just that in MSDOS, they converted all names to uppercase. In FAT32 they don't do it but its still case-insensitive. So "FooBar.bar" and "fOObAR.BAR" are the same file and cannot reside together in the same dir.
Thomas :U
But if I store a file as FOOBAR.bar and I look in the directory entries for foobar.BAR, will I find it?
yes you will find it because you are using case-insensitive search like szCmpi.
Thomas :U
Perhaps this DOS app will help answer your questions.
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
; Quick and dirty.
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
.model small,c
.486
.stack
include support.asm
.data
LFN_FILE_INFO STRUCT
attributes dd 0
dosCreationTime dw 0
dosCreationDate dw 0
unused1 dd 0 ; Used for Windows 9x 64-bit format
dosAccessTime dw 0
dosAccessDate dw 0
unused2 dd 0 ; Used for Windows 9x 64-bit format
dosWriteTime dw 0
dosWriteDate dw 0
unused3 dd 0 ; Used for Windows 9x 64-bit format
fileSizeHigh dd 0
fileSizeLow dd 0
reserved db 8 dup(0)
longNameZ db 260 dup(0)
shortNameZ db 14 dup(0)
LFN_FILE_INFO ENDS
fi LFN_FILE_INFO <>
fileFindHandle dw 0
requiredAttributes db 0 ; normal
allowedAttributes db 0 ; normal
.code
.startup
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
mov bx,81h ; skip leading space
.WHILE al != 13 ; scan command line for CR
inc bx
mov al,es:[bx]
.ENDW
mov BYTE PTR es:[bx],0 ; replace with null
push ds
push es
mov ax,ds
push es
pop ds
mov es,ax
mov ax,714Eh ; LfnFindFirstFile
mov ch,es:requiredAttributes
mov cl,es:allowedAttributes
mov dx,82h ; ds:dx -> filespec
mov di,OFFSET fi ; es:di -> fi
mov si,1 ; specify DOS date/time values
stc
int 21h
pop es
pop ds
.IF CARRY?
.IF ax == 7100h
print "not supported",NL
jmp fini
.ELSE
print "unexpected error",NL
jmp fini
.ENDIF
.ELSE
mov fileFindHandle,ax
.ENDIF
print "long name = ",ADDR fi.longNameZ,NL
print "short name = ",ADDR fi.shortNameZ,NL
mov ax,71A1h ; LfnFindClose
mov bx,fileFindHandle
int 21h
fini:
print NL,"Press any normal key to exit...",NL
call waitkey
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
.exit
end
[attachment deleted by admin]
It does not answer my question precisely because it is a DOS app. I am not interested in the way DOS handles it, I am interested in the way it is actually stored.
Quote from: AeroASM on May 02, 2005, 10:33:42 AM
It does not answer my question precisely because it is a DOS app. I am not interested in the way DOS handles it, I am interested in the way it is actually stored.
When you run it under Windows, where do you think Windows is getting the information? The LFN Interrupt 21h functions were intended to allow DOS applications,
running under Windows, access to the Windows LFN system. These are Windows functions that were not available under DOS.
After adding a DIR /x to the end of runit.bat, if I run it under Windows 2000, I get:
D:\MASMDOS\New Folder>fileinfo fileinfo.asm
long name = fileinfo.asm
short name =
Press any normal key to exit...
D:\MASMDOS\NEWFOL~1>fileinfo filewithalongname.txt
long name = filewithalongname.txt
short name = FILEWI~1.TXT
Press any normal key to exit...
D:\MASMDOS\NEWFOL~1>dir /x
Volume in drive D has no label.
Volume Serial Number is 0C52-19F9
Directory of D:\MASMDOS\NEWFOL~1
05/02/2005 10:45a <DIR> .
05/02/2005 10:45a <DIR> ..
05/02/2005 03:49a 0 FILEWI~1.TXT filewithalongname.txt
05/02/2005 03:12a 56 makeit.bat
05/02/2005 04:33a 1,744 fileinfo.obj
05/02/2005 04:33a 1,951 fileinfo.exe
05/02/2005 04:33a 6,439 fileinfo.zip
05/02/2005 10:45a 74 runit.bat
05/02/2005 04:33a 2,299 fileinfo.asm
7 File(s) 12,563 bytes
2 Dir(s) 32,662,487,040 bytes free
D:\MASMDOS\NEWFOL~1>pause
Press any key to continue . . .
If I change the name of fileinfo.asm to mixed case, I get:
D:\MASMDOS\New Folder>fileinfo fileinfo.asm
long name = FileInfo.asm
short name = FILEINFO.ASM
Press any normal key to exit...
D:\MASMDOS\NEWFOL~1>fileinfo filewithalongname.txt
long name = filewithalongname.txt
short name = FILEWI~1.TXT
Press any normal key to exit...
D:\MASMDOS\NEWFOL~1>dir /x
Volume in drive D has no label.
Volume Serial Number is 0C52-19F9
Directory of D:\MASMDOS\NEWFOL~1
05/02/2005 10:45a <DIR> .
05/02/2005 10:45a <DIR> ..
05/02/2005 03:49a 0 FILEWI~1.TXT filewithalongname.txt
05/02/2005 03:12a 56 makeit.bat
05/02/2005 04:33a 1,744 fileinfo.obj
05/02/2005 04:33a 1,951 fileinfo.exe
05/02/2005 04:33a 6,439 fileinfo.zip
05/02/2005 10:45a 74 runit.bat
05/02/2005 04:33a 2,299 FILEINFO.ASM FileInfo.asm
7 File(s) 12,563 bytes
2 Dir(s) 32,662,487,040 bytes free
D:\MASMDOS\NEWFOL~1>pause
Press any key to continue . . .
The names returned by the function exactly match the names returned by the
Windows DIR command. If you modify the code to display additional fields from the structure I think you will find that they also match the corresponding information returned by DIR.
But why are not all of the short filenames displayed with dir /x?
Quote from: AeroASM on May 02, 2005, 06:02:20 PM
But why are not all of the short filenames displayed with dir /x?
I think it is because there is no short name entry in the directory for files where the long name and the short name would be the same. I currently have no way to verify this for Windows 2000/XP. Under Windows 98 SE I was able to find and view the directory entries for these files using a (DOS) disk editor. It seems that Windows 98 SE handles the directory entries somewhat differently than Windows 2000/XP. For example, the files FILEINFO.OBJ and FILEINFO.ZIP have only short name entries, and these entries seem to (I did not examine every field) follow the normal DOS DIRENTRY structure, with an attribute value of 20h (archive).
DIRENTRY STRUCT
deName db '????????'
deExtension db '???'
deAttributes db ?
deReserved db 10 dup(?)
deTime dw ?
deDate dw ?
deStartCluster dw ?
deFileSize dd ?
DIRENTRY ENDS
For the files that have a long file name, the long name occupies multiple long file name directory entries, each with an attribute value of 0Fh (a value that was not defined for DOS AFAIK). The layout conforms to my most recent documentation (which was based on advance information for "Chicago", before the release of Windows 95), except each character occupies two bytes.
000001A0: 46 49 4C 45 49 4E 46 4F - 4F 42 4A 20 00 2D B3 85 FILEINFOOBJ .-¦à
000001B0: A2 32 A2 32 00 00 24 24 - A2 32 1B 77 D0 06 00 00 ó2ó2..$$ó2 w- ..
000001C0: 46 49 4C 45 49 4E 46 4F - 5A 49 50 20 00 30 B3 85 FILEINFOZIP .0¦à
000001D0: A2 32 A2 32 00 00 39 24 - A2 32 1C 78 27 19 00 00 ó2ó2..9$ó2 x' ..
000001E0: 42 6E 00 61 00 6D 00 65 - 00 2E 00 0F 00 37 74 00 Bn.a.m.e...¤.7t.
000001F0: 78 00 74 00 00 00 FF FF - FF FF 00 00 FF FF FF FF x.t...____..____
Physical Sector: Cyl 1, Side 230, Sector 59
00000000: 01 66 00 69 00 6C 00 65 - 00 77 00 0F 00 37 69 00 f.i.l.e.w.¤.7i.
00000010: 74 00 68 00 61 00 6C 00 - 6F 00 00 00 6E 00 67 00 t.h.a.l.o...n.g.
00000020: 46 49 4C 45 57 49 7E 31 - 54 58 54 20 00 31 B3 85 FILEWI~1TXT .1¦à
00000030: A2 32 A2 32 00 00 2A 1E - A2 32 00 00 00 00 00 00 ó2ó2..*-ó2......
Some additional information is
here (http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/win9x/lfn_1voz.asp).
Quote from: MichaelW on May 02, 2005, 10:57:08 PM
Quote from: AeroASM on May 02, 2005, 06:02:20 PM
But why are not all of the short filenames displayed with dir /x?
I think it is because there is no short name entry in the directory for files where the long name and the short name would be the same.
And so why is FILEINFO.ASM displayed?
The short name did not appear until I used mixed case for the long name, and in my view FileInfo.asm and FILEINFO.ASM are not the same name even if they do specify the same file. Why using mixed case makes a difference I don't know. The only way I can see to really know would be to run a sufficient number of tests. To do this easily you would need convenient access to the directory entries under Windows XP, and I can see no reasonable way to do that.
I cannot recall ever noting a problem with accessing a file created/written (to a FAT 32 volume) under one version of Windows, from another version. This implies that the directory entries are compatible, both backward and forward. So perhaps only the naming conventions have changed, and it would be possible to accurately determine how the directory information is stored by experimenting with a DOS app running under Windows 9x.
How things are displayed is irelevant. It depends on the application that displays the information.
What you need to know is the phhysical layout of the directory entries for short and long filenames and the fact that there could be any combination of them: only LFN, LFN+SFN, only SFN.