No "." and ".." directories accessible if root directory does not contain any subdirectories

[erdmann]

related to ticket #76:

if the root directory has no "real" subdirectories, then the "pseudo" directories "." and ".." do not exist. The "pseudo" directories should be available and visible even if the root directory does not contain any real subdirectories.

[Valery V. Sedletski]

I just formatted the drive with fat12 (other FS'es should be the same) and the "dir" command shows "." and "..". So, the root directory is obviously empty and contains "." and "..". So, your case is not reproduced on my machine. Maybe, you're have some nuances in your configuration? FS_FINDFIRST/FS_FINDNEXT always adds "." and ".." to each root directory, and I cannot imagine how it can omit them. The only case if the root directory is considered a non-root one. (A root directory is the one which has the property: ulDirCluster == pVolInfo->BootSect.bpb.RootDirStrtClus).

[erdmann]

How about multiple partitions ? It's unclear to me if RootDirStrtClus relates to the start of the whole disk or only the start of the partition. The normal value for "RootDirStrtClus" is always "2" and seems to indicate that it relates to a partition start so how could that ever fail to match for any FAT partition ?
I don't know what "ulDirCluster" is.

The problem occurs with a FAT16 partition on a USB stick with multiple partitions. It works correct with a FAT32 partition. Therefore the problem seems to be FAT16. And I formatted with format x: /FS:FAT16 (that is: your formatting utility)

[Valery V. Sedletski]

Heh, just noticed: on exFAT, "." and ".." are missing in non-root directories too. So, I need to fix that too. (exFAT does not have neither "." nor ".." in its directories).

The normal value for "RootDirStrtClus?" is always "2" and seems to indicate that it relates to a partition start so how could that ever fail to match for any FAT partition ?

DirCluster is a start cluster of a directory. RootDirStrtClus is a DirCluster of a root directory. Yes, on FAT32, it is usually 2, which means that it usually follows FAT (the very first cluster). Cluster numbers 0 and 1 are reserved. On FAT12/FAT16, root directory starts right after last FAT, too. But here, root dir belongs to a reserved area, which has not assigned any cluster number. Cluster 2 immediately follows the root directory. In fat32.ifs, each directory is specified by its DirCluster. So, to accomodate FAT root dir case, I assigned it a special "fake" value 1. So, directory is FAT root directory if and only if its DirCluster == 1. So, each directory has its dir cluster, including FAT root dir.

It can fail to match if the directory is not a root one. So, I add "." and ".." to root dirs only (though, It looks like I need to add "." and ".." to non-root dirs for exFAT too). They have ulDirCluster == pVolInfo->BootSect.bpb.RootDirStrtClus. pVolInfo->BootSect.bpb.RootDirStrtClus == 2 on FAT12/FAT16, on FAT32 it is usually 2. And on exFAT, it is usually 5 or 6 (they follow an Allocation bitmap and UpCase table, which have lesser cluster values).

And yes, clusters always relate to a partition, not a whole disk. Whole disk has sectors, only. Cluster is a FAT concept. HPFS has no clusters, for example. It has sectors. And JFS is divided to blocks of 4 KB, which aren't called clusters. So, the notion of cluster is not defined outside FAT and only FAT partitions are divided to clusters.

The problem occurs with a FAT16 partition on a USB stick with multiple partitions. It works correct with a FAT32 partition. Therefore the problem seems to be FAT16. And I formatted with format x: /FS:FAT16 (that is: your formatting utility)

Strange. I have two FAT partitions, one FAT12 (32 MB in size) and another FAT16 (having 2 GB in size). Both show "." and "..". So, these are multiple partitions too. I think, it does not matter if it is an USB stick or a SATA hard disk.

PS: Sorry, did not noticed your message until now. I did not received any notification by email.

[Valery V. Sedletski]

I have a 16 GB stick, which I split to a 1.8 GB FAT16 partition, and a 12 GB exFAT partition. Under OS/2, I see both "." and ".." on a newly-formatted partitions. But in WinXP, I see neither "." nor ".." on a FAT16 partition. But this is Windows. In OS/2, all is correct. (FAT16 partition is primary, exFAT partition is logical. WinXP sees only FAT16 primary partition, OS/2 sees both).

[Valery V. Sedletski]

OK, I taught fat32.ifs to show "." and ".." in each exFAT subdirectory, since r370.

Lars, maybe, your stick is dirty? I tried to set my partition dirty with "f32stat o: /dirty" and now I see

[h:\]dir

 Volume in drive H is FAT16          Serial number is 0BEA:2121
SYS0002: Система не может найти указанный файл. "H:\*"
              0 bytes in 0 files and 0 dirs
  1 897 234 432 bytes free

If I set it clean with "f32stat o: /clean" command, I see the following:

[h:\]dir

 Volume in drive H is FAT16          Serial number is 0BEA:2121
 Directory of  H:\*

 2.10.18  21:34         <DIR>             0  .
 2.10.18  21:34         <DIR>             0  ..
 2.10.18  20:52              20           0  CHKDSK.LOG
             20 bytes in 1 file and 2 dirs    32 768 bytes allocated
  1 897 234 432 bytes free

Maybe, your stick is dirty?

[abwillis]

Replying to valerius:

I have a 16 GB stick, which I split to a 1.8 GB FAT16 partition, and a 12 GB exFAT partition. Under OS/2, I see both "." and ".." on a newly-formatted partitions. But in WinXP, I see neither "." nor ".." on a FAT16 partition. But this is Windows. In OS/2, all is correct. (FAT16 partition is primary, exFAT partition is logical. WinXP sees only FAT16 primary partition, OS/2 sees both).

FAT16, when handled by the OS/2 kernel also does not show the "." or "..", as you saw in WinXP, I don't know that it is wrong to have the FAT32 driver to show them for FAT16 or not but it does appear to be non-standard.

[Valery V. Sedletski]

2abwillis: As you could notice, ifs.inf (in the article about FS_FINDFIRST) states that

In the case of a global search in a directory, the first two entries in that directory as reported by the FSD should be '.' and '..' ( current and the parent directories).

So, it seems, in the in-kernel FAT driver, IBM-ers violate their own rules.

HPFS and JFS follow these rules -- they have both "." and ".." in each directory (including root one).

[erdmann]

I can confirm that with SVN rev 378, this problem has been fixed. The "." and ".." directories will properly be displayed for FAT32 and also for FAT16 partitions IF they are handled by fat32.ifs (in any case, empty root directory or not).
I can also confirm that with the built-in FAT16 driver, FAT16 partitions will NOT show the "." and ".." directories if the root directory is empty (as valerius stated: " IBM-ers violate their own rules").
Closing this bug.