SVN rev 361: FAT32.IFS doesn't display "." and ".." in FAT[/12/16/32] root directory

[erdmann]

I have written myself this batch file to do a chkdsk run just in case a removable volume is corrupted:

@echo off del d:\chkdsk.log>NUL & for %%D in (c: g: h: i: j: k:) do (if not exist %%D\. (echo Checking drive %%D & chkdsk %%D /F>>d:\chkdsk.log)) pause

This batch file works fine if the volume is managed by JFS.IFS but "if not exist %%D\." always fails on a volume managed by FAT32.IFS even if that volume is not corrupted. That's because FAT32.IFS does not report the existence of the "." and ".." directories.

[Valery V. Sedletski]

Just tried to go to my FAT32 drive, cd to a w:\tmp subdirectory on it, and tried "cd . and cd ..". Both commands works just fine. If "." or/and ".." didn't existed, the commands should fail, but they don't.

You redirect the log into d:\chkdsk.log. Didn't you thought that CHKDSK already saves its log into the chkdsk.log file, so a conflict should occur, so trying to redirect a log into chkdsk.log should fail? JFS CHKDSK doesn't write its log, so you don't observe any errors. Did you tried to redirect the log into an another file? Should it fail then?

PS: Why do you think that "if not exist %%d\." should work at all? Tried your script with cmd.exe and two disks, one HPFS, another JFS -- doesn't work the same way as with FAT32. And your script writes numerous errors with 4os2 (which I'm using as a shell)

[Valery V. Sedletski]

Hm, but the following simpler script:

if exist w:\. echo lalala!

doesn't display "lalala!" only on drives managed by fat32.ifs, so here you're right. But the following script (provided w:\tmp exists):

if exist w:\tmp\. echo lalala!

Displays "lalala!" on fat32.ifs-managed drive too. So, this effect appears to be present only in the root directory.

Thanks for reporting this problem!

[Valery V. Sedletski]

Hm, Looking at FAT drive root directory by a disk editor, I don't see "." and ".." records at all. The root directory starts from Volume Label, but no "." or "..". Non-root subdirectories have such records, though. So, it looks to be normal for a FAT drive. Though, I, maybe, need to create fake "." and ".." records for FAT root directory.

[erdmann]

As far as I know the directories "." and ".." are always virtual, that is you should not find these directory names on the disk but they should be "created" and managed and reported back by the IFS.

The "." is the current directory, that is if the IFS gets a CHANGE_DIR or QUERY_DIR (DosSetCurrentDir? / DosQueryCurrentDir?) request with this target directory, for CHANGE_DIR,it should return with NO_ERROR and keep the current working directory. For a QUERY_DIR it should report the full current working directory.

The ".." directory is the parent directory. If the IFS gets a CHANGE_DIR request with this target directory, it needs to "shorten" the existing current working directory by the name of the lowest level subdirectory in order to move up a directory level.

If the IFS is requested to report all (files and) subdirectories of a directory (DosFindFirst/DosFindNext?), it also has to report back a "." and ".." subdirectory.

If you look at a JFS formatted partition you will see that directories "." and ".." exist in every directory, even the root directory. I guess for a CHANGE_DIR request on ".." in the root directory, the IFS should report an error "DIRECTORY_DOES_NOT_EXIST" and keep the current working directory.

I admit that I have not yet looked at the root directory of a drive formatted with the kernel built-in FAT16 filesystem. Therefore I don't know what it reports back.

[erdmann]

Ok, for a NTFS formatted drive (under Windows), the "." and ".." directories do not show up in a directory listing of the root directory. That may be the same for any FAT filesystem.

Nonetheless, these directories still have to be supported also for the root directory (under NTFS, a "dir ." in the root directory shows all files/subdirectories in the root directory except for "." and "..", a "cd .." in the root directory does nothing but does not report an error/wrong path).

[Valery V. Sedletski]

"." and ".." are not pure virtual, at least on FAT. On FAT, they are present on disk in each non-root subdirectory, but not in the root. (I did not noticed yet, that they are missing in the root directory in FAT). But if they are missing, they should be emulated.

If you cd to .. in the root directory, ".." just refers to current directory (the same as "." does) and does nothing. It does not return an error.

[Valery V. Sedletski]

Hi, since r368, I added the fake "." and ".." dir entries to each FAT12/FAT16/FAT32/exFAT root directory. Now "dir" command shows them and the test script succeeds. (I added several dir entries with negative numbers in a directory block with number -1, so the implementation was relatively simple) So, please, test.

[erdmann]

SVN rev 368 fixes thiSVN rev 368 fixes this bug. Closing.