-
-
Notifications
You must be signed in to change notification settings - Fork 396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Invalid characters being put in Gist filenames #1044
Comments
@shanalikhan I'm sure you are busy but I would very much appreciate a time slice if you have one. |
I understand your concern. Have you check the procedure to revert older Gist.
In |
@shanalikhan I will try the newer version for you. In the meanwhile, I still do firmly believe that the invalid characters should be removed. I'd rather revert using a clone on my local machine rather than doing it through Gist's clunky interface. I think it's a relatively simple task to do this. I might consider a PR if you are OK with these changes:
|
@rcdailey : You might just want to try cloning or fetch/pull your gist again after doing an upload with version You may also want to inspect your gist to make sure that the "old" files with the bad names are not there. For example, you might have |
@karl-lunarg Thanks for the quick response. I did force-push up my settings from VS Code after updating, I do not see the filenames renamed:
|
And I have:
I'm on Linux, but if I were experiencing the same problem, I would expect What do these files look like in your gist, as seem from the GitHub web interface? Mine looks like: |
It makes sense to me that if VS Code had a generic variable for "separator", that it would be |
VS Code does have such a generic variable and it is called The code in @rcdailey : Are you in a position to look into this? |
I haven't done vs extension development before, but I'd like to look at it
for you. I just don't know where to start.
…On Mon, Sep 23, 2019, 9:20 AM Karl Schultz ***@***.***> wrote:
VS Code does have such a generic variable and it is called path.sep and
it does what you say.
The code in service/file.service.ts, function GetFile is supposed to
generate a gistName that substitutes the native path separator with '|'.
On Windows, path.sep is "\\" and I wonder if the split function is
handling it as expected. We'd have to debug this function with a
Windows-style path to see what is going on.
@rcdailey <https://github.com/rcdailey> : Are you in a position to look
into this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1044?email_source=notifications&email_token=AANPU5XTC6OG2QBHVOR5HTTQLDGEVA5CNFSM4IXEXREKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7LATKQ#issuecomment-534120874>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AANPU5QL62WF5U6OYADYCXDQLDGEVANCNFSM4IXEXREA>
.
|
@karl-lunarg unfortunately it looks like pipe characters are forbidden as well: https://gist.github.com/doctaphred/d01d05291546186941e1b7ddc02034d3 Need to use underscores. |
I didn't know where to start either a couple of weeks ago. :-) You might search for "building vs code extensions", etc. I think I started here and here. Basically, you'll have to install node.js on your system. Then fork/clone this repo. Run |
I see. Even if we fix the extension to properly put '|' in the gistName, cloning the gist to Windows won't work because of the '|' in the name. Correct? Oddly, Linux allows this and still lets me deal with files with the pipe embedded in the name:
I suppose that I can keep the shell from interpreting pipe as a pipe as long as I keep the filenames enclosed.
works. If a git clone of the gist fails on Windows because of the '|', then we're in the position of not being friendly about cloning the gist (hopefully an unusual case) or coming up with another way to represent path separators. The gist seems to be a flat directory and so it seems hard to try to do real directories there. Why do you think that underscore might be good for this? Couldn't any settings file have an underscore in its name, which would probably cause the extension to download it into the wrong place? I don't know right now how to fix this. I didn't come up with the '|' thing and I sort of thought that was an established GitHub/Gist convention. And if the gist can't be cloned on Windows, then it looks like cloning a gist containing snippets wasn't tested on Windows. And this isn't hard to imagine since it seems like it shouldn't be common to clone a gist. (But I totally get why you would want to) p.s. I just tried cloning my gist (with filenames containing '|') to a Windows machine and it failed to checkout the files with the '|'. |
When looking at |
I think that it is because snippets is a directory in the User settings area. I also think that the choice of storing snippets in a You'd have to loop in @shanalikhan on this, but I'd guess that there's some sort of attempt here to have a generalized facility to store more things from the User settings area in the gist and this would include things in directories as well as files like It would be a little dangerous to assume that any gistName that has an underscore in it implies that it goes into a subdir in the User area. If that assumption is made and a future version of VS Code came out that started using a file called I suppose that your approach would work if this extension code sort of singled out the snippets files and supported storing them in the gist specifically. That is, when the extension uploads a snippet file, it would form the gistName by In other words, this would be sort of "tagging" snippet files with some sort of prefix to form the gistName and then undoing the tag to come up with a local directory name. The tag could be a GUID or anything else like "banana", but it would obviously be better to be more mnemonic. The downside is that explicit support would have to be added if VS Code ever added a new feature that stored state in a new dir in the User area like "stickyNotes". But I don't think that would happen often and isn't necessarily a bad thing. I poked around a bit and found that being unable to clone (checkout, actually) files with illegal filenames is not that uncommon on Windows. There are a few projects out there that ran into this and had to take steps to avoid having things like ':' in their filenames. So it seems like some effort to fix this would be worthwhile. |
Probably graduating from gists would be the best solution. What you really want is the ability to represent directories in the gist. But since gists don't allow directories, you'd have to use an actual git repo. I think adding support for arbitrary repo hosts (like Gitlab, Bitbucket) which lets you host private repositories, would be the answer. Gitlab specifically would be a great choice. Instead of using a gist, you'd use a git repo to store the settings. You can then use actual directories which will be nicer and you avoid these hacky workarounds. |
Yeah, I agree (sorry for the long previous reply) But for now, this could be fixed pretty simply if this extension tries to store a selected list of User files and directories in the gist. That way, you could guarantee that there are no underscore surprises. In file.service.ts GetFile(), change the '|' to '_'. when forming the gistName. In file.service.ts CreateDirTree(), change the code to split on '_.' And probably split on '|', if present, to handle old gists. Need to think about snippet files that could have '_' in their names. |
Don't forget that this isn't just an issue with snippet files, there's this monstrosity too:
I'd much rather contribute support for fully fledged git repositories if I were to spend any of my time on this. I know that's a much bigger effort, but I think it's worth it in the long haul. The worst thing about hacks is not the hack itself, but becoming complacent in the solution. |
@rcdailey Yes there is already issue opened to support Git Repo. in Settings Sync. People have placed bounties about 200-300$ in #413. Feel free to send PR and get the bounty price, it would really help Settings Sync! I think it's better to close this issue and instead innovate on supporting Git in Settings Sync to allow more flexibility and features to users. |
🐛 Describe the bug
Certain files are written with invalid characters to the Gist which prohibits them from being cloned via Git on Windows, due to the limitations Windows places on allowed characters in filenames. In this case, the backslash (
\
) character is present in a few files:bd3d4befe38185704bf0fc875e9deed6\configuration.json
snippets\cpp.json
When attempting to clone this Gist via SSH, it fails:
The backslash characters break on Windows.
🌴 Visual Studio Code Version : [ 1.38.1 ]
🌴 Code Settings Sync Version : [ 3.4.2 ]
🌴 Standard or Insiders : [ Standard ]
🌴 Portable or Installed : [ Installed ]
🌴 OSS or Official Build : [ Official Build ]
🌴 Operating System : [ Windows 10 x64 Professional ]
🌴 Proxy Enabled: [ No ]
🌴 Gist Id: [ N/A ]
📰 To Reproduce
Steps to reproduce the behavior:
💪 Expected behavior
The clone should succeed. To fix the issue will require removing the incompatible characters from the filenames. You could use a dash or an underscore, for example.
For context: The reason I want to clone the Gist is to revert to a previous version of my VS Code settings. There is no built-in revert command that I've seen, so I decided to do it manually. Between 2 machines I'm working on, Settings Sync is constantly overwriting settings between machines by uploading extensions that I've uninstalled already.
The text was updated successfully, but these errors were encountered: