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

Feature/implement windows parser and on drive letter #206

Conversation

stagnation
Copy link
Contributor

No description provided.

@stagnation stagnation marked this pull request as draft June 4, 2024 13:57
@stagnation stagnation force-pushed the feature/implement-windows-parser-and-on-drive-letter branch 4 times, most recently from 4df2fb7 to 21eea46 Compare June 10, 2024 10:42
pkg/filesystem/local_directory_windows.go Outdated Show resolved Hide resolved
pkg/filesystem/path/builder.go Outdated Show resolved Hide resolved
pkg/filesystem/path/builder.go Outdated Show resolved Hide resolved
pkg/filesystem/path/builder.go Outdated Show resolved Hide resolved
pkg/filesystem/path/relative_scope_walker.go Outdated Show resolved Hide resolved
pkg/filesystem/path/stringer.go Outdated Show resolved Hide resolved
@stagnation stagnation force-pushed the feature/implement-windows-parser-and-on-drive-letter branch from 5ab271a to af92c74 Compare June 13, 2024 07:10
To give better error messages for which file or directory operation
fails.
@stagnation stagnation force-pushed the feature/implement-windows-parser-and-on-drive-letter branch from af92c74 to fedee3e Compare June 13, 2024 07:18
pkg/filesystem/local_directory_test.go Outdated Show resolved Hide resolved
pkg/filesystem/path/builder.go Outdated Show resolved Hide resolved
pkg/filesystem/path/builder.go Outdated Show resolved Hide resolved
pkg/filesystem/path/builder.go Outdated Show resolved Hide resolved
pkg/filesystem/path/builder.go Outdated Show resolved Hide resolved
pkg/filesystem/path/builder_test.go Outdated Show resolved Hide resolved
pkg/filesystem/path/builder.go Show resolved Hide resolved
pkg/filesystem/path/windows_parser.go Outdated Show resolved Hide resolved
pkg/filesystem/path/unix_parser.go Outdated Show resolved Hide resolved
pkg/filesystem/path/windows_parser.go Outdated Show resolved Hide resolved
@stagnation stagnation force-pushed the feature/implement-windows-parser-and-on-drive-letter branch 3 times, most recently from 829d800 to 2806e8b Compare June 17, 2024 14:54
pkg/filesystem/local_directory_test.go Outdated Show resolved Hide resolved
pkg/filesystem/path/builder.go Outdated Show resolved Hide resolved
pkg/filesystem/path/builder.go Outdated Show resolved Hide resolved
pkg/filesystem/path/builder.go Show resolved Hide resolved
pkg/filesystem/path/builder_test.go Outdated Show resolved Hide resolved
pkg/filesystem/path/trace.go Outdated Show resolved Hide resolved
pkg/filesystem/path/windows_parser.go Outdated Show resolved Hide resolved
pkg/filesystem/path/windows_parser.go Show resolved Hide resolved
pkg/filesystem/path/windows_parser.go Outdated Show resolved Hide resolved
pkg/filesystem/path/windows_parser.go Outdated Show resolved Hide resolved
@stagnation stagnation force-pushed the feature/implement-windows-parser-and-on-drive-letter branch from 2806e8b to b60a04d Compare June 18, 2024 12:54
@stagnation stagnation force-pushed the feature/implement-windows-parser-and-on-drive-letter branch 2 times, most recently from daac6d8 to 144774b Compare June 19, 2024 08:57
@stagnation stagnation force-pushed the feature/implement-windows-parser-and-on-drive-letter branch from 144774b to e7cd08c Compare June 19, 2024 09:26
Copy link
Member

@EdSchouten EdSchouten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking pretty good. Thanks for working on this!

pkg/filesystem/path/trace.go Show resolved Hide resolved
"github.com/stretchr/testify/require"
"google.golang.org/grpc/codes"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Add empty line between github.com and golang.org imports, for consistency with the rest of the code base.


func validateWindowsPathComponent(component string) error {
if strings.ContainsFunc(component, unicode.IsControl) || strings.ContainsAny(component, "<>:\"/\\|?*") {
return status.Errorf(codes.InvalidArgument, "Path component contains a control character or invalid character %#v.", component)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove the trailing dot. Also move the %#v to the right place in the sentence.

return status.Errorf(codes.InvalidArgument, "Path component %#v contains a control character or invalid character %#v", component)

That said, the general pattern in the Buildbarn codebase is to never format errors with values that also happen to be arguments of the function. Probably better to do this?

if strings.ContainsFunc(component, unicode.IsControl) {
    return status.Error(codes.InvalidArgument, "Path component contains control characters")
}
if strings.ContainsAny(component, "<>:\"/\\|?*") {
   return status.Error(codes.InvalidArgument, "Path component contains reserved characters")
}

And then let the caller do a util.StatusWrapf(err, "Invalid path component %#v", component.String()).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that there are also some additional restrictions on Windows, such as filenames not being allowed to end with dots or whitespace. And there are obviously reserved names such as LPT1. But whatever. I think we should only add checks for that if it ever becomes problematic. This should do.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point on the former! I did not make that connection, just thought about the error myopically. That is a great rule.

Argh windows... "But wait, there is more!"

}
return GotDirectory{Child: parent}, remainder, nil
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we add a call to validateWindowsPathComponent() here? This ensures that we also don't parse malformed paths.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding such a check would also allow you to get rid of

	if strings.ContainsRune(path, '\x00') {
		return nil, status.Error(codes.InvalidArgument, "Path contains a null byte")
	}

Because validateWindowsPathComponent() also does that for you.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking slightly ahead: if the strings.ContainsRune(path, '\x00') check is removed from NewWindowsParser(), then it can no longer return any errors. That also removes the need for having MustNewWindowsParser().

if err != nil {
return err
return util.StatusWrapf(err, "Failed to stat component %#v", childPath)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/component//, because it's not actually a path component but a full path? Also add .GetUNIXString(). Same with the other calls below.

@EdSchouten
Copy link
Member

Hey @stagnation ,

I just processed the remaining comments myself and merged this change. Thanks a lot for working on this!

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

Successfully merging this pull request may close these issues.

2 participants