directory/folder completion not working on virtual drive

[Eric Pement]

I think I'm trying to do something pretty simple, and I know that it works in CMD, but it's not working in TCC. Maybe someone can suggest what I'm doing wrong.

I have a virtual drive P (a cloud storage service virtual drive provided by pCloud), with folders in it. From a TCC prompt, if I type a letter or two of a directory name, I want to use the TAB key to complete the directory name. Tab completion of partial directory/folder names occurs transparently and perfectly on the C: drive -- e.g., "cd ba<TAB>" will cycle through all the directories beginning with "ba" on the C: drive. However, the same behavior does not occur on the P: drive.

I am attaching an animated GIF to illustrate this behavior. (It runs only once, as I find endless loops annoying.) Note especially that I start off using TCC to show the problem, then when I switch to cmd.exe, TAB completion of the folder name occurs just fine, but when I switch back to tcc.exe, now the TAB key doesn't complete anything.

Note also that If I type "cd", space, and then hit TAB, it will cycle through the directory names. But if I enter just one letter of a directory, TCC refuses to complete the directory name.

In my normal environment, I do not have the environment variable FILECOMPLETION defined. However defining it ( set FILECOMPLETION=cd cdd rmdir pushd:dirs; ) has no effect in a command session. Any helpful suggestions, tweaks, or questions are welcome.

 

[vefatica]

Do wildcards work (dir /a:d *)? ... full paths (cd p:\t<tab>)? What do @FSTYPE and @READY say about p:?

 

[Eric Pement]

Do wildcards work (dir /a:d *)? ... full paths (cd p:\t<tab>)? What do @FSTYPE and @READY say about p:?

1. The wildcard command to show directories works fine. All the top-level folders/directories appear with dir /a:d *

2. Tab-completion does not work with drive prefixes, unless no characters appear at the root level. For example, cd p:\<tab> completes and cycles through every directory, but cd p:\t<tab> does nothing, even though a directory p:\tech exists.

3. The function %@FSTYPE[p] says the file system is exFAT, and %@READY[p] returns 1, meaning that the drive is ready.

Feel free to ask anything else.

 

[vefatica]

The function %@FSTYPE[p] says the file system is exFAT

That might be a clue. The FS is actually Callback File System (CBFS); so says GoogleAI, suggesting that locally it might look like NTFS (which it doesn't). I don't know enough about such things to say more. I suppose Rex will comment.

 

[Eric Pement]

That might be a clue. The FS is actually Callback File System (CBFS); so says GoogleAI, suggesting that locally it might look like NTFS (which it doesn't). I don't know enough about such things to say more. I suppose Rex will comment.

That's good information. Here's some more: when I plug a 2TB USB drive into my desktop PC, which is formatted as exFAT, it becomes drive E: and the directory completion using TAB works normally, just as it works for the C: drive. It's that virtual drive P which isn't working as expected.

Which raises a couple more questions: (1) Why does @FSTYPE return "exFAT" instead of "CBFS"? (2) Why is CMD.EXE able to perform TAB-completion of partial directory names, but TCC.EXE cannot do it for the same drive?

 

[Joe Caverly]

Windows APIs cannot identify CBFS directly.

pCloud Drive is a CBFS virtual filesystem.

It reports itself as a normal drive type (usually Fixed).

To detect it:

Check for CBFS driver

Check filesystem name

Check absence in Win32_DiskDrive

Use CBFS COM API for guaranteed detection


Here is a single,
self‑contained,
correct PowerShell function that returns $true / $false for “is this drive CBFS?” using the three reliable detection methods:

CBFS driver present

Filesystem name matches known CBFS/pCloud FS names

Drive has no backing physical disk

function Test-CBFSDrive {
    param(
        [Parameter(Mandatory=$true)]
        [string]$DriveLetter   # e.g. "P:"
    )

    # Normalize input
    $dl = $DriveLetter.TrimEnd('\')

    # --- 1. CBFS driver present -----------------------------------------
    $cbfsDriver = Get-WmiObject Win32_SystemDriver |
                  Where-Object { $_.Name -like "cbfs*" }

    if (-not $cbfsDriver) {
        return $false   # No CBFS driver → cannot be CBFS
    }

    # --- 2. Filesystem name check ---------------------------------------
    $ld = Get-CimInstance Win32_LogicalDisk |
          Where-Object { $_.DeviceID -eq $dl }

    if ($ld) {
        # Known CBFS/pCloud FS names
        $cbfsNames = @("CBFS","pCloudFS","pCloud","CBFSVFS")

        if ($cbfsNames -contains $ld.FileSystem) {
            return $true
        }
    }

    # --- 3. No physical disk backing ------------------------------------
    # CBFS volumes never appear in Win32_DiskDrive
    $physical = Get-CimInstance Win32_DiskDrive |
                ForEach-Object {
                    Get-CimInstance Win32_DiskPartition -Filter "DiskIndex=$($_.Index)" |
                    ForEach-Object {
                        Get-CimInstance Win32_LogicalDisk -Filter "DeviceID='$($_.DeviceID)'"
                    }
                }

    $isPhysical = $physical | Where-Object { $_.DeviceID -eq $dl }

    if (-not $isPhysical) {
        # Virtual + CBFS driver loaded → CBFS
        return $true
    }

    return $false
}

Usage:

Test-CBFSDrive "P:"

The preceeding was generated by AI.

Not tested.

Joe

 

[vefatica]

Which raises a couple more questions: (1) Why does @FSTYPE return "exFAT" instead of "CBFS"? (2) Why is CMD.EXE able to perform TAB-completion of partial directory names, but TCC.EXE cannot do it for the same drive?

I don't think Windows knows about CBFS. TCC's tab-completion is quite a bit more robust that CMD's. Maybe it uses something CMD doesn't ... something which doesn't work as expected with that drive type.

You might also try this.

wmiquery . "Select * from Win32_LogicalDisk Where Name='p:'"

Keep in mind that Windows only sees what the driver reports.

 

[Eric Pement]

RELEVANT NEWS for the problem of TAB-completion of partial directory names not working on a virtual drive with CBFS (file system) :

This issue only appears for the internal TCC commands cd, cdd, pushd, copydir, movedir, rmdir, rd, and tree . . .

BUT not for the internal TCC commands chdir, dir, pdir, xdir, nor for any other common commands like type, copy, ren, del, touch, list, etc.

This last one really surprises me, because according to the documentation for "CD / CHDIR", "CD and CHDIR are synonyms. You can use either one."

In plain English, "cd \f<TAB>" fails to complete the directory name, but "chdir \f<TAB>" does complete the directory name and cycle through all directories that match the prefix letter(s).

For what it's worth, I get this same behavior from TCC v35, and I have been able to obtain a partial workaround for "CD" by
1. Use Take Command "Options > TCC > Commands", and move CD to "Disabled Commands"
2. Create an alias, as "aliascd=*chdir", and put it in my startup file.

I say this is a "partial" workaround, because it still doesn't handle the problem of cdd, pushd, copydir, movedir, rmdir, rd, and tree.

Am I the only person on this forum who uses pCloud? I think someone should be able to reproduce this issue.

Sincere thanks to everyone who has replied to me on this thread. @Rex, I hope you're listening.

 

[rconn]

This is a bug in the pCloud filesystem driver.

When you enter 'f' and press Enter, TCC passes either "f*" or "f*." (depending on a number of things, including how Windows has identified the filesystem) to the Windows FindFirstFile API, which pCloud is intercepting. In the Windows world, those strings are identical -- a ".*" will match any file, whether or not it has an extension. But pCloud is failing the file match, probably because the developer erroneously thought a "." required an extension. (Which IIRC it does in Linux.)

If you go to that directory and do a "dir f*" and a "dir f*.*" you'll see what's happening.