 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Windows Forum / Windows 98 / General Topics / October 2007File size/Number of file limits
Hello, We are having problems combining 2 directories under Windows 98. Basically, we are appending a few hundred files to a larger directory called 'Contracts'. When we copy over the files we get the following error: 'The directory or file cannot be created.' Both directories are on the primary C drive. The target 'contracts' directory is 599MB and contains 16135 objects. Is there a limit for FAT32 filesystems running Windows 98 which would cause this error to happen. I thought maybe there was a 600MB cap and it wasn't allowed to go over, however i copied a 5 MB file in there instead of some of the smaller files and it went to 605MB. I had a feeling it was the filenames, containing & symbols and spaces, however they seem to copy fine elsewhere. > Hello, > [quoted text clipped - 3 lines] > error: 'The directory or file cannot be created.' Both directories are > on the primary C drive. If you pop over to win XP Newsgroup, I just asked a similar question with extensive replies (inc FAT32) search for "Folder limitations" HTH Rod. Actually, it would be as easy, and require less downloading, to search Google for this News group related to that information. We have done rather extensive reviews. The short is: Yes, you may have addressed issues related to the limits imposed. You may also run across issues related to *like named* folders, e.g., c:\Contracts\contracts and how these are saved in Fat.  SignatureMEB http://peoplescounsel.orgfree.com ________ | > Hello, | > [quoted text clipped - 10 lines] | HTH | Rod. The FAT32 file system has a limit of 65k filename entries. Each DOS 8.3 filename will require one entry - long filenames require more. So it is quite likely that you have exceeded the filename limitation. AFAIK there is no size limitation, other than the partition size. SignatureJeff Richards MS MVP (Windows - Shell/User) > Hello, > [quoted text clipped - 12 lines] > I had a feeling it was the filenames, containing & symbols and spaces, > however they seem to copy fine elsewhere. > The FAT32 file system has a limit of 65k filename entries. Each DOS 8.3 > filename will require one entry - long filenames require more. anyone know of a program that removes any unnecessary long filenames that are only there to preserve the Case of the filenames ? something to run at a directory hierarcy that removes all long filenames for the files that not have more than 8+3 chars (where only difference between the dos filename and the long FileName is small and BIG letters) | > The FAT32 file system has a limit of 65k filename entries. Each DOS 8.3 | > filename will require one entry - long filenames require more. [quoted text clipped - 6 lines] | (where only difference between the dos filename and the | long FileName is small and BIG letters) Search Google for things like *mass file name changer* and look at some of the offerings. Some of them have some interesting potential uses. SignatureMEB http://peoplescounsel.orgfree.com ________ |> The FAT32 file system has a limit of 65k filename entries. Each DOS |> 8.3 filename will require one entry - long filenames require more. | | anyone know of a program that removes any unnecessary long filenames | that are only there to preserve the Case of the filenames ? Well... "START button, Run, WinFile". It often is said that WinFile only understands SFNs. Maybe copy the files in a folder to a new folder. Theoretically, you will get a folder full of files with only SFNs. The source folder likely remains unaltered. I'm not sure of any unexpected, additional, untoward consequences! WARNINGS: (a) Don't get carried away & drop the LFNs in any system folder. If they are used in the Registry-- there could be trouble! (b) Even if not mentioned in the Registry, loosing LFNs may be extremely uncomfortable, when you try to recall what the files & folders are. (c) Looks like it takes a little getting used to. Don't do anything with it you might regret in the morning! (d) WinFile doesn't seem to honor the following setting... "START, Settings, Folder Options, View tab", & bolt "Show all files"; may as well uncheck "Hide file extensions..." too. Therefore, you may not see all files that exist in a folder. | something to run at a directory hierarcy that removes all | long filenames for the files that not have more than 8+3 chars | (where only difference between the dos filename and the | long FileName is small and BIG letters) SignatureThanks or Good Luck, There may be humor in this post, and, Naturally, you will not sue, Should things get worse after this, PCR pcrrcp@netzero.net > | something to run at a directory hierarcy that removes all > | long filenames for the files that not have more than 8+3 chars > | (where only difference between the dos filename and the > | long FileName is small and BIG letters) What is the issue with file names with lower-case vs upper-case letters? >> | something to run at a directory hierarcy that removes all >> | long filenames for the files that not have more than 8+3 chars [quoted text clipped - 3 lines] > What is the issue with file names with lower-case vs upper-case > letters? normal FAT-filenames (8+3 "dosfilenames") is allways saved in uppercase only. (even though windows filemanager shows them as lowercase with the first letter Uppercase) So if you write any letter in the filename as lowercase when you make the file, windows have to create a long-file-name too for it so it can save the correct case somewhere. Most people don't care about the casing of the filename though (especially since windows shows all-uppercase filnames as lowercase anyway...) so if you have lot of files that is not longer than 8+3 then you can save space in your directories if you could run something that killed the long-file-name for just those files. (I guess I could do that with some normal multirename-tool and set it to rename all files with 8+3 chars or shorter, that don't have any unicode or other special chars not allowed in dos, in a certain directory with subdirectories, to be all UPPERCASE. But that will probably be a whole bunch of clicks to make it do that, and I'm not sure it will actually remove the long-file-name, maybe only make it upperase too?) What you will loose is that filnames like "AbiSuite" will be shown as "Abisuite" but I can live with that... :-) (but the orginal poster had longer filenames so he have no use for this anyway) >>> | something to run at a directory hierarcy that removes all >>> | long filenames for the files that not have more than 8+3 chars [quoted text clipped - 7 lines] >uppercase only. (even though windows filemanager shows them as >lowercase with the first letter Uppercase) To force Explorer to "allow all uppercase names", go to View -> Folder Options -> View and check the appropriate box. >So if you write any letter in the filename as lowercase when you >make the file, windows have to create a long-file-name too for it so [quoted text clipped - 11 lines] >be a whole bunch of clicks to make it do that, and I'm not sure it will >actually remove the long-file-name, maybe only make it upperase too?) Yes, that's what happens. You need to make a copy instead. C:\WIN98SE>echo blah > a:\MiXdCaSe.TxT C:\WIN98SE>ren a:\MiXdCaSe.TxT MIXDCASE.TXT C:\WIN98SE>copy a:\MIXDCASE.TXT a:\UPPRCASE.TXT C:\WIN98SE>debug -L 100 0 13 1 -D 100 100 41 4D 00 49 00 58 00 44-00 43 00 0F 00 0D 41 00 AM.I.X.D.C....A. 110 53 00 45 00 2E 00 54 00-58 00 00 00 54 00 00 00 S.E...T.X...T... 120 4D 49 58 44 43 41 53 45-54 58 54 20 00 3D C8 7D MIXDCASETXT .=.} 130 5D 37 5D 37 00 00 98 7E-5D 37 02 00 07 00 00 00 ]7]7...~]7...... 140 55 50 50 52 43 41 53 45-54 58 54 20 00 21 9D 7E UPPRCASETXT .!.~ 150 5D 37 5D 37 00 00 98 7E-5D 37 03 00 07 00 00 00 ]7]7...~]7...... >What you will loose is that filnames like "AbiSuite" will be >shown as "Abisuite" but I can live with that... :-) > >(but the orginal poster had longer filenames so he have >no use for this anyway) - Franc Zabkar SignaturePlease remove one 'i' from my address when replying by email. |> | something to run at a directory hierarcy that removes all |> | long filenames for the files that not have more than 8+3 chars [quoted text clipped - 3 lines] | What is the issue with file names with lower-case vs upper-case | letters? As teebo may have said, I think someone may have wanted to get a maximum number of files into one directory. To do that, one must eliminate LFNs (Long File Names). In Win98, a LFN is created for a file that has mixed-case letters-- even if there is no other reason to do so (I do believe). SignatureThanks or Good Luck, There may be humor in this post, and, Naturally, you will not sue, Should things get worse after this, PCR pcrrcp@netzero.net > |> | something to run at a directory hierarcy that removes all > |> | long filenames for the files that not have more than 8+3 chars [quoted text clipped - 9 lines] > mixed-case letters-- even if there is no other reason to do so (I do > believe). http://support.microsoft.com/kb/161982 http://support.microsoft.com/kb/130598 John |> |> | something to run at a directory hierarcy that removes all |> |> | long filenames for the files that not have more than 8+3 chars [quoted text clipped - 12 lines] | http://support.microsoft.com/kb/161982 | http://support.microsoft.com/kb/130598 Those articles are a good find, especially the first which says... ....Quote 161982............ Windows 95/98/Me and Windows NT/2000/XP behave differently because of the way the two platforms store mixed-case short (8.3) filenames. Windows NT/2000/XP stores each mixed-case short filename in a single directory entry with its case preserved. Windows 95/98/Me, however, creates two directory entries for mixed-case short filenames: one entry is for the 8.3 name in all upper-case (as MS-DOS stores filenames); the second is for a long filename entry that stores the filename in mixed-case. Although Windows 95/98/Me stores mixed-case short filenames with two directory entries, it stores all upper-case short filenames in a single directory entry just as MS-DOS does. ....EOQ.......................... I THINK it very nicely confirms what I THINK I've been saying all along about SFNs in Win98! Although at first I thought Zabcar had proved XP would also build a LFN when only mixed-case letters were the reason for it... news:nudrh3pikoih509oou62as0i30ka8kgase@4ax.com ...Quote............... OK, I now have an XP box for testing. I used Notepad to save a text file as ... ...snip... Mix_CaSe.TxT ...snip... XP Explorer displays the files exactly as saved, as does a Dir from a CMD window. However, on a W98 box the filenames are displayed as ... ...snip... Mix_CaSe.TxT ...snip... Debug shows the following directory structure: ...snip... 240 E5 4D 00 69 00 78 00 5F-00 43 00 0F 00 F5 61 00 .M.i.x._.C....a. 250 53 00 65 00 2E 00 54 00-78 00 00 00 54 00 00 00 S.e...T.x...T... 260 E5 49 58 5F 43 41 53 45-54 58 54 20 00 75 CE 16 .IX_CASETXT .u.. 270 21 28 21 28 00 00 CF 16-21 28 00 00 00 00 00 00 !(!(....!(...... 280 41 4D 00 69 00 78 00 5F-00 43 00 0F 00 F5 61 00 AM.i.x._.C....a. 290 53 00 65 00 2E 00 54 00-78 00 00 00 54 00 00 00 S.e...T.x...T... 2A0 4D 49 58 5F 43 41 53 45-54 58 54 20 00 75 CE 16 MIX_CASETXT .u.. 2B0 21 28 21 28 00 00 D0 16-21 28 05 00 04 00 00 00 !(!(....!(...... ...snip... ...EOQ.................. ...I think I see now that "Mix_CaSe.TxT" isn't JUST mixed-case-- it also contains an underline (_) -- which is a special character -- & that's what caused the LFN to generate, going by the 2nd article you posted: "To create a file name that will be displayed in all uppercase letters, include an extended character (such as a comma or space) in the filename." Thanks! | John SignatureThanks or Good Luck, There may be humor in this post, and, Naturally, you will not sue, Should things get worse after this, PCR pcrrcp@netzero.net >...I think I see now that "Mix_CaSe.TxT" isn't JUST mixed-case-- it also >contains an underline (_) -- which is a special character -- & that's >what caused the LFN to generate, going by the 2nd article you posted: >"To create a file name that will be displayed in all uppercase letters, >include an extended character (such as a comma or space) in the >filename." I don't think the underscore is a "special" or "extended" character. I believe an extended character is any character that is not allowed in a standard 8.3 DOS file name. Unfortunately I no longer have an XP box so I'll have to leave it to others to prove you wrong. :-) BTW, is FILE0000.EXT uppercase or mixed case? Is file0000.ext lowercase or mixed case? ;-) - Franc Zabkar SignaturePlease remove one 'i' from my address when replying by email. >BTW, is FILE0000.EXT uppercase or mixed case? Upper case. You wouldn't need a LFN entry for that one. >Is file0000.ext lowercase or mixed case? ;-) I'd say lower case, but it doesn't matter. The important thing is that you'd need two directory entries for that name: one for the DOS version (FILE0000.EXT), and one for the lower-case version. SignatureTim Slattery MS MVP(Shell/User) Slattery_T@bls.gov http://members.cox.net/slatteryt >>...I think I see now that "Mix_CaSe.TxT" isn't JUST mixed-case-- it also >>contains an underline (_) -- which is a special character -- & that's [quoted text clipped - 7 lines] >a standard 8.3 DOS file name. Unfortunately I no longer have an XP box >so I'll have to leave it to others to prove you wrong. :-) It appears that in Win98 the underscore is not a special character, ie no LFN is created. C:\WIN98SE>echo blah > a:\________.___ (8.3) C:\WIN98SE>debug -L 100 0 13 1 -D 100 100 5F 5F 5F 5F 5F 5F 5F 5F-5F 5F 5F 20 00 2A C6 40 ___________ .*.@ 110 5F 37 5F 37 00 00 C7 40-5F 37 02 00 07 00 00 00 _7_7...@_7...... -Q - Franc Zabkar SignaturePlease remove one 'i' from my address when replying by email. |>>...I think I see now that "Mix_CaSe.TxT" isn't JUST mixed-case-- it |>>also contains an underline (_) -- which is a special character -- & [quoted text clipped - 18 lines] | 110 5F 37 5F 37 00 00 C7 40-5F 37 02 00 07 00 00 00 _7_7...@_7...... | -Q I'll buy that for Win98SE. But remember your very own XP directory dump after creating "Mix_CaSe.TxT" on a floppy...?... 240 E5 4D 00 69 00 78 00 5F-00 43 00 0F 00 F5 61 00 .M.i.x._.C....a. 250 53 00 65 00 2E 00 54 00-78 00 00 00 54 00 00 00 S.e...T.x...T... 260 E5 49 58 5F 43 41 53 45-54 58 54 20 00 75 CE 16 .IX_CASETXT .u.. 270 21 28 21 28 00 00 CF 16-21 28 00 00 00 00 00 00 !(!(....!(...... 280 41 4D 00 69 00 78 00 5F-00 43 00 0F 00 F5 61 00 AM.i.x._.C....a. 290 53 00 65 00 2E 00 54 00-78 00 00 00 54 00 00 00 S.e...T.x...T... 2A0 4D 49 58 5F 43 41 53 45-54 58 54 20 00 75 CE 16 MIX_CASETXT .u.. 2B0 21 28 21 28 00 00 D0 16-21 28 05 00 04 00 00 00 !(!(....!(...... Looks to me XP found a reason to generate a LFN, despite John John's excellent article... http://support.microsoft.com/kb/161982 PRB: Win 95/98/Me Copies Fewer Files in Root Directories than Windows NT/2000/XP ...saying: "Windows NT/2000/XP stores each mixed-case short filename in a single directory entry with its case preserved." Therefore...!... (a) The article is wrong (& John John must be punished), or (b) An XP-irradiated underline (_) does qualify as a "special" or "extended" character-- & YOU must be punished! | - Franc Zabkar | -- | Please remove one 'i' from my address when replying by email. SignatureThanks or Good Luck, There may be humor in this post, and, Naturally, you will not sue, Should things get worse after this, PCR pcrrcp@netzero.net ...snip | BTW, is FILE0000.EXT uppercase or mixed case? Is file0000.ext | lowercase or mixed case? ;-) I find myself in full agreement with Slattery on that issue! | - Franc Zabkar | -- | Please remove one 'i' from my address when replying by email. SignatureThanks or Good Luck, There may be humor in this post, and, Naturally, you will not sue, Should things get worse after this, PCR pcrrcp@netzero.net >> |> | something to run at a directory hierarcy that removes all >> |> | long filenames for the files that not have more than 8+3 chars [quoted text clipped - 9 lines] >> mixed-case letters-- even if there is no other reason to do so (I do >> believe). Win 95/98/Me Copies Fewer Files in Root Directories than Windows NT/2000/XP >http://support.microsoft.com/kb/161982 Microsoft's article states that ... "Windows 95/98/Me and Windows NT/2000/XP behave differently because of the way the two platforms store mixed-case short (8.3) filenames. Windows NT/2000/XP stores each mixed-case short filename in a single directory entry with its case preserved. Windows 95/98/Me, however, creates two directory entries for mixed-case short filenames: one entry is for the 8.3 name in all upper-case (as MS-DOS stores filenames); the second is for a long filename entry that stores the filename in mixed-case." The above statement is misleading. Files of the type ... FILENAME.ext filename.EXT filename.ext FILENAME.EXT ... are stored by XP as a single uppercase directory entry (ie no LFN). Two bits in a reserved byte within that same directory entry indicate whether the name and/or the extension are to be displayed as uppercase or lowercase. XP understands this byte, but Win9x/DOS ignores it, which means that the latter OSes cannot preserve the filename's original case. If "mixed case" is taken to mean files of the type FiLeNaMe.ExT, then both XP and Win9x generate LFNs. - Franc Zabkar SignaturePlease remove one 'i' from my address when replying by email. There is a limit of 64K-1 (65,635) entries in folders but any folder or filename over 13 characters will use 3 or more entries. One normally hits the limit around 25-30,000 but it can be less with many long file names. ...Alan -- Alan Edwards, MS MVP Windows - Internet Explorer http://dts-l.org/index.htm >Hello, > [quoted text clipped - 12 lines] >I had a feeling it was the filenames, containing & symbols and spaces, >however they seem to copy fine elsewhere. Each file within the directory has around 40 characters in the name so that would explain it. Thanks everyone for your help. > There is a limit of 64K-1 (65,635) entries in folders but any folder > or filename over 13 characters will use 3 or more entries. One [quoted text clipped - 24 lines] > >I had a feeling it was the filenames, containing & symbols and spaces, > >however they seem to copy fine elsewhere. > We are having problems combining 2 directories under Windows 98. Win-98 - First edition or Second edition? > Is there a limit for FAT32 filesystems running Windows 98 which > would cause this error to happen. Assuming you are running Win-98 second edition, then yes you probably are dealing with FAT-32. But you should check that. The claimed max number of files per directory is 65535. http://www.microsoft.com/technet/technetmag/issues/2006/07/WindowsConfidential/ The max number of files possible using FAT-32: 268,435,437 http://en.wikipedia.org/wiki/File_Allocation_Table#Design The number 268,435,437 (max number of files possible under FAT32) is equal to 16k x 16k (ie, 16k directories, each with 16k files) or 4k x 64k (ie - 4k directories, each with 64k files). For test purposes, I've filled a 500 gb volume on a win-98 system with slightly over 3 million files across almost 200,000 directories. The limiting factor for the number of files on a win-98 system (under FAT-32) will be the number of allocation units available on the volume. You can't have more files than you have allocation units (aka clusters). Micro$oft doesn't like Win-9x to have volumes with more than 2 million clusters, and will allow the cluster count to rise above the 2 million number only when the volume exceeds 64 gb. Typically, the cluster count reaches a maximum of 4 million given a volume size of 128 gb. As far as this being a long file name issue, I don't think so. The size of the directory tables are variable under FAT-32 and can grow as needed. If you double-click the "my computer" icon and right-click on your C drive and select properties, you will be told the type of file system. If you right-click on a particular directory and select properties, you will be told the number of files in that directory. > The claimed max number of files per directory is 65535. You seem to think (or you are implying) that this is incorrect, by one of your yet unknown methods are we to assume that you can also overcome this limitation? In the Directory Table the object's first cluster is held in a 16 bits wide feild so, being that objects cannot share clusters, the maximum number of objects that can be contained in the Directory Table is 65536. > The max number of files possible using FAT-32: 268,435,437 > > The number 268,435,437 (max number of files possible under FAT32) is > equal to 16k x 16k (ie, 16k directories, each with 16k files) or 4k x > 64k (ie - 4k directories, each with 64k files). Sigh... Where did you get this mathematical explanation for the 268,435,437 file or cluster limit on FAT32? FAT32 is 32 bits wide but 4 bits are reserved or unused so it is really 28 bits wide and 2^28 less a couple of bits (for something or other, that I am not sure why) = 268,435,437 clusters. > The limiting factor for the number of files on a win-98 system (under > FAT-32) will be the number of allocation units available on the > volume. You can't have more files than you have allocation units (aka > clusters). Well duh! And you can't puts 3 pints in a quart! > As far as this being a long file name issue, I don't think so. The > size of the directory tables are variable under FAT-32 and can grow as > needed. Well think again! Long filenames require at lest 3 extra directory object entries, so unless you figured out how to "widen" the 16 bit field, long file names will reduce the number of available directory objects. I expect that you will soon tell us that you have blown FAT32's 4gb file size limit! John Typo correction in the before last paragraph. LFN's require at least *2* extra entries, (requires 3 or more entries). >> The claimed max number of files per directory is 65535. > [quoted text clipped - 37 lines] > > John >> The claimed max number of files per directory is 65535. > [quoted text clipped - 4 lines] >clusters, the maximum number of objects that can be contained in the >Directory Table is 65536. Actually, a FAT32 directory could hold many more entries than this. The specification says that FAT32 drivers must have this limit. That's because a FAT32 directory is always searched sequentially, so the bigger it gets, the more time you spend searching it. NTFS directories, by contrast, are stored as BTrees (balanced trees), which makes searching *much* faster. (It does slow down the process of retrieving all file names, but not hugely.) The spec says this: <quote> * DIR_FileSize is a 32-bit field. For FAT32 volumes, your FAT file system driver must not allow a cluster chain to be created that is longer than 0x100000000 bytes, and the last byte of the last cluster in a chain that long cannot be allocated to the file. This must be done so that no file has a file size > 0xFFFFFFFF bytes. This is a fundamental limit of all FAT file systems. The maximum allowed file size on a FAT volume is 0xFFFFFFFF (4,294,967,295) bytes. * Similarly, a FAT file system driver must not allow a directory (a file that is actually a container for other files) to be larger than 65,536 * 32 (2,097,152) bytes. </quote> and since each entry is 32 bytes long, that means no more than 65,536 entries per directory. SignatureTim Slattery MS MVP(DTS) Slattery_T@bls.gov http://members.cox.net/slatteryt >>>The claimed max number of files per directory is 65535. >> [quoted text clipped - 31 lines] > and since each entry is 32 bytes long, that means no more than 65,536 > entries per directory. Isn't the DIR_FileSize field used to record the size of the file? Hence the 4,294,967,295 bytes maximum? Shouldn't the maximum number of objects in the directory be limited by DIR_FstClusLO or DIR_FstClusHI fields? Isn't the file location just kept by the first cluster in the Directory Table, and isn't the rest of the cluster map outside of the Directory Table, just sort of "daisy chained" within the actual and successive clusters? Much of this is new territory to me ;-) so I'm just being inquisitive, I always appreciate getting good solid information on some of these scantly documented (and complicated!) subjects. John >> The spec says this: >> [quoted text clipped - 17 lines] >Isn't the DIR_FileSize field used to record the size of the file? Hence >the 4,294,967,295 bytes maximum? Exactly >Shouldn't the maximum number of objects in the directory be limited by >DIR_FstClusLO or DIR_FstClusHI fields? As the quote shows, the 65,536 entries limit is purely arbitrary. The spec says that any conforming driver must impose this limit. It's not the result of anything in the structure/ > Isn't the file location just >kept by the first cluster in the Directory Table, and isn't the rest of >the cluster map outside of the Directory Table, just sort of "daisy >chained" within the actual and successive clusters? Yes, the directory entry points to the first cluster (or allocation unit). To find where the rest of the file is, you have to look in the File Allocation Table itself, where the entry for a given cluster will point to the next cluster in the file. And another chain keeps track of free space. >Much of this is new territory to me ;-) so I'm just being inquisitive, I >always appreciate getting good solid information on some of these >scantly documented (and complicated!) subjects. There is solid documentation of FAT32 (unlike NTFS). It's here: http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx MS does not (AFAIK) make that kind of documentation of NTFS available - at least without paying for it. There is an open source program that's trying to make NTFS available for Linux. They have published documentation at http://www.linux-ntfs.org/doku.php SignatureTim Slattery MS MVP(Shell/User) Slattery_T@bls.gov http://members.cox.net/slatteryt > As the quote shows, the 65,536 entries limit is purely arbitrary. The > spec says that any conforming driver must impose this limit. It's not > the result of anything in the structure/ I see, the limit is imposed be the file system driver. Thanks for steering me straight on this. John I performed a series of serial file generations to see how many files could be created in a subdirectory while changing the length of the file name. The following table shows the file-name length and the corresponding number of files that could be created before this eror was generated: The directory or file cannot be created 6.0 - 65,533 6.3 - 32,767 12.3 - 21,845 15.3 - 21,845 17.3 - 21,845 23.3 - 16,384 47.3 - 13,107 63.3 - 9,362 96.3 - 7,282 So in the first case, with a filename composed of 6 characters (and no suffix) I was able to create 65,533 files. In the second case, the filename was composed of 6-characters.3-characters, and the directory would only hold 32,767 of those files. So as the filename length increases, there is a decrease in the number of possible files. According to the OP: > The target 'contracts' directory is 599MB and contains 16135 > objects. We are appending a few hundred files. We get the > following error: > 'The directory or file cannot be created. For the above to happen, the existing 16,135 files would have to have long file names (about 20 characters, more likely 23 characters, possibly slightly more). > I performed a series of serial file generations to see how many files > could be created in a subdirectory while changing the length of the > file name. > > 6.0 - 65,533 > 6.3 - 32,767 strange that it starts to use LFN-names when you add extension to the filenames? are you sure you didn't got lowercase in the fileextensions somehow? > 12.3 - 21,845 > 15.3 - 21,845 [quoted text clipped - 3 lines] > 63.3 - 9,362 > 96.3 - 7,282 >> I performed a series of serial file generations to see how many files >> could be created in a subdirectory while changing the length of the [quoted text clipped - 6 lines] >the filenames? are you sure you didn't got lowercase in the >fileextensions somehow? It appears that LFNs are created (in Win9X) unless both the name and extension are in uppercase 8.3 format. C:\WIN98SE\TEMP>echo blah > dummy C:\WIN98SE\TEMP>copy dummy a:\lowrcase.txt C:\WIN98SE\TEMP>copy dummy a:\UPPRCASE.TXT C:\WIN98SE\TEMP>copy dummy a:\FILENAME.ext C:\WIN98SE\TEMP>debug -L 100 0 13 1 -D 100 100 41 6C 00 6F 00 77 00 72-00 63 00 0F 00 2F 61 00 Al.o.w.r.c.../a. 110 73 00 65 00 2E 00 74 00-78 00 00 00 74 00 00 00 s.e...t.x...t... 120 4C 4F 57 52 43 41 53 45-54 58 54 20 00 62 2D 3F LOWRCASETXT .b-? 130 5E 37 5E 37 00 00 C8 3E-5E 37 02 00 07 00 00 00 ^7^7...>^7...... 140 55 50 50 52 43 41 53 45-54 58 54 20 00 B8 30 3F UPPRCASETXT ..0? 150 5E 37 5E 37 00 00 C8 3E-5E 37 03 00 07 00 00 00 ^7^7...>^7...... 160 41 46 00 49 00 4C 00 45-00 4E 00 0F 00 F6 41 00 AF.I.L.E.N....A. 170 4D 00 45 00 2E 00 65 00-78 00 00 00 74 00 00 00 M.E...e.x...t... 180 46 49 4C 45 4E 41 4D 45-45 58 54 20 00 35 34 3F FILENAMEEXT .54? 190 5E 37 5E 37 00 00 C8 3E-5E 37 04 00 07 00 00 00 ^7^7...>^7...... - Franc Zabkar SignaturePlease remove one 'i' from my address when replying by email. > >> 6.0 - 65,533 > >> 6.3 - 32,767 In the first case (6.0) the 6 characters of the file name were numbers. In the second case (6.3) the file name was a set of 6 numbers.txt (.txt = lower case). So win-9x (and ME?) create 2 entries for a short name (8.3) if the name has any lower case letters - the first entry being an all upper-case version, only for DOS's benefit? Yes? Is this because DOS can't handle mixed-case 8.3 names, or because MS didn't want to deal with confused user support calls along the lines of "I can see the file right there, but when I try to copy it I keep getting file-not-found !" Given a command-line oriented OS like DOS, perhaps MS felt it was best to remove case-confusion and convert all file names to upper case all the time. I'd like to see what happens when you create some mixed-case 8.3 files on a FAT-32 drive under XP and then boot the drive under DOS and do a DIR. >> >> 6.0 - 65,533 >> >> 6.3 - 32,767 [quoted text clipped - 6 lines] >name has any lower case letters - the first entry being an all >upper-case version, only for DOS's benefit? Yes? It appears that way. >Is this because DOS can't handle mixed-case 8.3 names, or because MS >didn't want to deal with confused user support calls along the lines >of "I can see the file right there, but when I try to copy it I keep >getting file-not-found !" I don't have too many answers, I just have results. :-) >Given a command-line oriented OS like DOS, perhaps MS felt it was best >to remove case-confusion and convert all file names to upper case all >the time. That sounds plausible. >I'd like to see what happens when you create some mixed-case 8.3 files >on a FAT-32 drive under XP and then boot the drive under DOS and do a >DIR. Sorry, I no longer have an XP machine. - Franc Zabkar SignaturePlease remove one 'i' from my address when replying by email. >So win-9x (and ME?) create 2 entries for a short name (8.3) if the >name has any lower case letters - the first entry being an all >upper-case version, only for DOS's benefit? Yes? > >Is this because DOS can't handle mixed-case 8.3 names, ... You may want to have a look at this old post of mine. The MS-DOS names are all lowercase, even the volume name. "MS-DOS names for Kodak camera files": http://groups.google.com/group/microsoft.public.win98.gen_discussion/msg/7bca1af 3946fd88c - Franc Zabkar SignaturePlease remove one 'i' from my address when replying by email. >I performed a series of serial file generations to see how many files >could be created in a subdirectory while changing the length of the [quoted text clipped - 31 lines] >long file names (about 20 characters, more likely 23 characters, >possibly slightly more). I created a file named "dummy" and then copied it to several files on a floppy diskette as follows. ================================================================== C:\WIN98SE>echo blah > dummy C:\WIN98SE>for %i in (7 78 789 7890 78901 789012 7890123) do copy dummy a:\01234567890123456%i.txt C:\WIN98SE>dir a: 012345~3 TXT 7 10-27-07 8:49a 012345678901234567.txt 012345~4 TXT 7 10-27-07 8:49a 0123456789012345678.txt 012345~5 TXT 7 10-27-07 8:49a 01234567890123456789.txt 012345~6 TXT 7 10-27-07 8:49a 012345678901234567890.txt 012345~7 TXT 7 10-27-07 8:49a 0123456789012345678901.txt 012345~8 TXT 7 10-27-07 8:49a 01234567890123456789012.txt 012345~9 TXT 7 10-27-07 8:49a 012345678901234567890123.txt ================================================================== I then dumped the directory structure using Debug. It appears that there are 3 entries for filenames of 21 characters, and 4 entries for 22 and 23 characters. ===================================================================== 4A0 42 33 00 34 00 35 00 36-00 37 00 0F 00 7B 38 00 B3.4.5.6.7...{8. 4B0 39 00 30 00 31 00 2E 00-74 00 00 00 78 00 74 00 9.0.1...t...x.t. 4C0 01 30 00 31 00 32 00 33-00 34 00 0F 00 7B 35 00 .0.1.2.3.4...{5. 4D0 36 00 37 00 38 00 39 00-30 00 00 00 31 00 32 00 6.7.8.9.0...1.2. 4E0 30 31 32 33 34 35 7E 37-54 58 54 20 00 94 53 46 012345~7TXT ..SF 4F0 5B 37 5B 37 00 00 27 46-5B 37 11 00 07 00 00 00 [7[7..'F[7...... 500 43 74 00 00 00 FF FF FF-FF FF FF 0F 00 1B FF FF Ct.............. 510 FF FF FF FF FF FF FF FF-FF FF 00 00 FF FF FF FF ................ 520 02 33 00 34 00 35 00 36-00 37 00 0F 00 1B 38 00 .3.4.5.6.7....8. 530 39 00 30 00 31 00 32 00-2E 00 00 00 74 00 78 00 9.0.1.2.....t.x. 540 01 30 00 31 00 32 00 33-00 34 00 0F 00 1B 35 00 .0.1.2.3.4....5. 550 36 00 37 00 38 00 39 00-30 00 00 00 31 00 32 00 6.7.8.9.0...1.2. 560 30 31 32 33 34 35 7E 38-54 58 54 20 00 1D 54 46 012345~8TXT ..TF 570 5B 37 5B 37 00 00 27 46-5B 37 12 00 07 00 00 00 [7[7..'F[7...... 580 43 78 00 74 00 00 00 FF-FF FF FF 0F 00 3B FF FF Cx.t.........;.. 590 FF FF FF FF FF FF FF FF-FF FF 00 00 FF FF FF FF ................ 5A0 02 33 00 34 00 35 00 36-00 37 00 0F 00 3B 38 00 .3.4.5.6.7...;8. 5B0 39 00 30 00 31 00 32 00-33 00 00 00 2E 00 74 00 9.0.1.2.3.....t. 5C0 01 30 00 31 00 32 00 33-00 34 00 0F 00 3B 35 00 .0.1.2.3.4...;5. 5D0 36 00 37 00 38 00 39 00-30 00 00 00 31 00 32 00 6.7.8.9.0...1.2. 5E0 30 31 32 33 34 35 7E 39-54 58 54 20 00 6E 54 46 012345~9TXT .nTF 5F0 5B 37 5B 37 00 00 27 46-5B 37 13 00 07 00 00 00 [7[7..'F[7...... ===================================================================== - Franc Zabkar SignaturePlease remove one 'i' from my address when replying by email. >It appears that >there are 3 entries for filenames of 21 characters, and 4 entries for >22 and 23 characters. Sorry, that should have been "3 entries for filenames of 22 characters, and 4 entries for 23 and 24 characters". - Franc Zabkar SignaturePlease remove one 'i' from my address when replying by email. >I performed a series of serial file generations to see how many files >could be created in a subdirectory while changing the length of the [quoted text clipped - 20 lines] >would only hold 32,767 of those files. So as the filename length >increases, there is a decrease in the number of possible files. From my testing I think the rule is as follows. If we consider the SFN (32 bytes) to be one directory entry, then each entry assigned to the LFN can store 13 characters. So to determine how many entries a particular file requires, we count the characters in the name, extension, and any periods, and divide the result by 13. For example, a 96.3 filename would have 100 characters. Its LFN would then require 8 entries (100 / 13 = 7.69), and its SFN would need one more. Dividing 65535 by 9 gives 7281.7. - Franc Zabkar SignaturePlease remove one 'i' from my address when replying by email. >* Similarly, a FAT file system driver must not allow a directory >(a file that is actually a container for other files) to be larger [quoted text clipped - 3 lines] >and since each entry is 32 bytes long, that means no more than 65,536 >entries per directory. I'm thinking that this restriction could in extreme circumstances result in file system corruption. For example, let's assume that the directory is full (65,536 entries) and that the machine has been booted in Win9x real DOS mode. What happens if you try to create an additional file? AFAICS, DOS sees the existing LFNs as deleted files (each entry has a leading 0xE5 flag byte), so wouldn't DOS then overwrite one of these LFNs? Or does Win9x DOS understand that these entries are LFNs even though it doesn't support them? - Franc Zabkar SignaturePlease remove one 'i' from my address when replying by email. >> * Similarly, a FAT file system driver must not allow a directory >> (a file that is actually a container for other files) to be larger >> than 65,536 * 32 (2,097,152) bytes. good to know that I never need more than 2MB to hold a directory list in memory :-) > I'm thinking that this restriction could in extreme circumstances > result in file system corruption. For example, let's assume that the > directory is full (65,536 entries) and that the machine has been > booted in Win9x real DOS mode. What happens if you try to create an > additional file? AFAICS, DOS sees the existing LFNs as deleted files nope! the LFNs are not marked as deleted files. The first char in the filename-part in the LFN-posts are a letter that describes number or LFN-posts the LFN-filename have. A is one LFN-post B is two, C is three etc. the special marking of the LFN-posts is instead by using fileattribute DiskLabel-System-Hidden-ReadOnly > (each entry has a leading 0xE5 flag byte), so wouldn't DOS then > overwrite one of these LFNs? Or does Win9x DOS understand that these > entries are LFNs even though it doesn't support them? dos without LFN-support understands them as "bad" and don't touch them. (And if you run old scandisk type of diskutilities, like norton disk doctor etc, and the find these "errorus lines" and removes them, nothing more than the long filenames is destroyed. the files can allways be used with the short names) >>> * Similarly, a FAT file system driver must not allow a directory >>> (a file that is actually a container for other files) to be larger [quoted text clipped - 28 lines] >long filenames is destroyed. the files can allways be used with the short >names) Thanks for correcting my disinformation. The directory structure is indeed as you describe. The following example is for a Win98 machine. =================================================================== C:\WIN98SE>rem > a:\longfilename.txt C:\WIN98SE>debug -l 100 0 13 1 -d 100 140 42 74 00 78 00 74 00 00-00 FF FF 0F 00 D4 FF FF Bt.x.t.......... 150 FF FF FF FF FF FF FF FF-FF FF 00 00 FF FF FF FF ................ 160 01 6C 00 6F 00 6E 00 67-00 66 00 0F 00 D4 69 00 .l.o.n.g.f....i. 170 6C 00 65 00 6E 00 61 00-6D 00 00 00 65 00 2E 00 l.e.n.a.m...e... 180 4C 4F 4E 47 46 49 7E 31-54 58 54 20 00 5B 6F 35 LONGFI~1TXT .[o5 190 5B 37 5B 37 00 00 70 35-5B 37 00 00 00 00 00 00 [7[7..p5[7...... -q =================================================================== My confusion arose from the results of my experimentation on an XP system (see the recent "UPPERCASE" thread). In that thread I observed several deleted entries in the directory structure even though I had not deleted any files. I had merely launched Notepad, typed "blah", and then selected File -> Save As to save my work as a text file. After exiting Notepad and using Debug to view the directory entries, I found entries corresponding to the newly created file, as well as entries with 0xE5 flag bytes which denote a deleted file. Maybe this behaviour is a consequence of an autosave function rather than some OS quirk, ie maybe Notepad automatically saves the latest copy on exit??? - Franc Zabkar SignaturePlease remove one 'i' from my address when replying by email. > Actually, a FAT32 directory could hold many more entries than this. > The specification says that FAT32 drivers must have this limit. That's nice to hear that it is just a rule with a number they chosed to be "enough" and not something forced by the format. I guess then you could relatively easily modify your filesystem drivers to a number you like more. (but some of your file-utilities may not see all your files then, and verry sloppily coded ones could perhaps crash) That said, I must say that I think 65536 is way more than enough that it is, if you want more than 10000 files in the same directory without hierachy, your program should really use some database instead. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.