Right-clicking and creating new files or folders doesn't resolve paths for .. and /

[humphd]

It's possible to right-click in the file tree and create a file (or filder) named ../something or just .., and the path isn't resolved, but rather the .. and / characters are treated as literals to be used in the filename itself.

First discovered by @Pomax in https://github.com/humphd/brackets/issues/434, and now I'm filing upstream, since this is really a bug in Brackets.

[tallandroid]

Works for me on mac. I created both a file and a folder with prefix to be .. in a subfolder. Both got created in the parent folder. However , the UI shows this

Can you confirm if the directory structure is as expected in the file system. In that case , its a bug with the File Tree UI.

[petetnt]

Nice find! I like how it sort of works how you would expect it to regarding creating files with relative paths and it also sort of works how you would expect it to work if they were just filenames.

Another case that brings really weird behavior is naving a file /foo.js. It's created as foo.js, but stays as /foo.js in the editor until refreshing.

I'd say the expected behavior would be showing a "filename cannot contain error", something similar to this Windows example:

[humphd]

@petetnt, I had the same thought, to show a "filename cannot contain..." error of some kind. I don't think you want people using the filename as a way to bypass pathing.

[petetnt]

@peterflynn noted on the mailing list (Brackets-Dev) that error/validation is there already, but it's not in a tooltip form but a modal error that appears when there are invalid characters. The "/" case is just failing:

[tallandroid]

Submitted a pull request : #11862

As @peterflynn pointed out , the validation is failing for this case.

The reason being, the validation checks for the basename of the file which strips out the /../ from the fullPath. So the validation code gets the basename which is perfectly valid.
Another weird thing I found was that / is being considered a valid character according to brackets for mac platforms, which in my opinion shouldn't be the case. Feel free to provide a counter point.

The pull request does change the inherent behavior of FileUtils.baseName though. It makes sense , cos if the fullpath contains the parent relative path , it should be returned along with the baseName. I preferred this over the option of creating a new function like FileUtils.getNormalizedPath and running the validation against that. Open to options.

[tallandroid]

This can be closed now.