The root directory of a Bucket File System is a special case. It is always the empty string; the only directory for which the name is not a "valid file name".

For all other FileSystemHandles (including other "root" directories), the name is specified by https://fs.spec.whatwg.org/#locating-an-entry:

entry’s name is the last item of locator’s path.

@a-sully Thanks for your reply.

entry’s name is the last item of locator’s path.

A file system path is a list of one or more strings. This may be a virtual path that is mapped to real location on disk or in memory, may correspond directly to a path on the local file system, or may not correspond to any file on disk at all. The actual physical location of the corresponding file system entry is implementation-defined.

These descriptions are a bit unclear to me, does it mean that different User-Agents may return different FileSystemHandle.name for the same path 'D:\'? (e.g. it's '\' in Chromium, but 'D:' in Firefox Extension.)

As far as I know if FileSystemHandle.name is '\' or 'D:' both will make vscode.dev unavailable.

Ah I see. This is currently not well-specified. The picker methods say to create:

a new FileSystemFileHandle associated with entry

... which has a few problems:

• This language doesn't make sense anymore in the wake of Give FileSystemHandles an associated path whatwg/fs#96. This spec needs to be updated accordingly (related to Broken references in File System Access #408, though realistically this is blocked on Add a serializable "permission root locator" to a FileSystemHandle whatwg/fs#131)

• The properties of the entry yielded from the file picker are not very well-defined:

  "Let entry be a file entry representing the selected file"

  This is very hand-wavy. We may want to make this more precise, perhaps poaching ideas from the <input type="file"> spec. Would you like to either file a new issue or update the title description of this issue to reflect that we need to better specify the name of the FileSystemHandle selected from a picker?

All that being said, '\' is not a valid file name (nor would it be once we update the criteria for a valid file name). Chromium appears to strip the drive letter from the path if you select a root (though we add it back in UI surfaces, e.g. for permissions) though I'm not sure off the top of my head why (@mkruisselbrink may know). Would you mind filing a new Chrome bug and pasting the URL here?

Firefox Extension

This looks very cool, by the way! :)

The path "/" likely doesn't have a valid file name either. The FileSystemHandle.name is '/' in Chromium, but '' in Firefox Extension.

If an invalid file name is a bug, then what should the name be?

it's '\' in Chromium, but 'D:' in Firefox Extension

I agree that both '\' and '/' are not valid names - or at least won't be once we address whatwg/fs#93

That issue relates to paths for the Bucket File System, though. What's not specified - but is necessary to safely allow access to the local file system - is the additional restrictions the user agent may put on file names. I imagine these restrictions will be non-normative once they are added to the spec.

For example, it looks like Chromium does not allow the colon character in file names, which explains why the drive letter is stripped....

If an invalid file name is a bug, then what should the name be?

...Good question! :)

The least-bad option might be to carve out an exception for drive roots ('/', 'D:', etc) in the same way we have done for the Bucket File System root. Whether that's '/' or '\' or '' or something else, I'm indifferent to... But it seems like it would be nice to pick one and specify it

I think that if the user agent cannot generate a valid file name for the root directory, reusing the empty string of the bucket file system is better than using path separators. Because developers only need to additionally consider this one special case.

However, probably generating a valid file name (e.g. "[root]") would have better compatibility than using an empty string.