Skip to content
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

stignore path seperator on windows #738

Open
jtagcat opened this issue Mar 6, 2022 · 4 comments
Open

stignore path seperator on windows #738

jtagcat opened this issue Mar 6, 2022 · 4 comments

Comments

@jtagcat
Copy link
Contributor

jtagcat commented Mar 6, 2022

https://docs.syncthing.net/users/ignoring.html

Escaped characters are not supported on Windows, where \ is the path separator.

I did some testing, essentially on windows alias "\"="/", mixing both acts as if you used / on *nix

@jtagcat
Copy link
Contributor Author

jtagcat commented Mar 6, 2022

  • Both / and \ is used as a path separator on Windows.
  • A pattern beginning with / → (path separator) (may be \ or /)

Additional digging in source code should give some exact answers.

@calmh
Copy link
Member

calmh commented Mar 6, 2022

I'm not sure if this is a question or a request of some sort? On Windows, often in general and in Syncthing in particular, both slash and backslash are valid path separators. c:/some/folder is a valid path as far as Syncthing is concerned.

@jtagcat
Copy link
Contributor Author

jtagcat commented Mar 7, 2022

More like a todo, that C:/hello\world/owo\foo/bar is all good and well, yea

@rodrymbo
Copy link

I'd assert that not everyone knows what a "directory separator" is, so on "users/ignoring.html", just before it mentions "directory separator" might be a good place to put in a sentence or two saying that / is the "directory separator", and that it works on Windows the same as other OSs. Maybe add that the usual Windows separator \ works too, but only on Windows (if that is the case)?

The example of .stignore on that page has wildcards and shows how they affect files that happen to be in subdirectories. It might be helpful to include (more) fully qualified paths (if they work) instead of relying only on wildcards? So, maybe

./logs/*

if it does in fact ignore files in a logs subdirectory just below the current root? Or if wildcards are in fact the only way to affect files in subdirectories, maybe include a few more examples of how one might do that without accidentally ignoring files in the root or other subdirectories.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants