I wasn't thinking about windows support when I originally wrote the uri/filesystem logic. As a result, many tests broke when we starting running them on windows via Appveyor. This PR includes the following fixes:
In remote_fs.go, make it very explicit when file paths are using URI paths (every function besides Clone) or system paths (only inside Clone).
This involves changing the return types of some functions, and renaming batchFileResult to just batchFile, etc. These changes also propagate to remote_fs_test.go.
In remote_fs.go, for Clone: explicitly convert the uris returned by walk/batchOpen to system file paths using FromSlash
In uris.go, create two versions of [path/filepath]hasPrefix[path/filepath]trimPrefix that follow the stdlib conventions of using / or os.PathSeparator
ensure that only the path... functions are used when dealing with uris
ensure that only the filepath... functions are used when dealing with system file paths (remote_fs_test.go)
In uris_test.go, ensure that only path... functions are used to create,manipulate file uris
I wasn't thinking about windows support when I originally wrote the uri/filesystem logic. As a result, many tests broke when we starting running them on windows via Appveyor. This PR includes the following fixes:
In
remote_fs.go, make it very explicit when file paths are using URI paths (every function besidesClone) or system paths (only insideClone).batchFileResultto justbatchFile, etc. These changes also propagate toremote_fs_test.go.In
remote_fs.go, forClone: explicitly convert the uris returned bywalk/batchOpento system file paths usingFromSlashIn
uris.go, create two versions of[path/filepath]hasPrefix[path/filepath]trimPrefixthat follow thestdlibconventions of using/oros.PathSeparatorpath...functions are used when dealing with urisfilepath...functions are used when dealing with system file paths (remote_fs_test.go)In
uris_test.go, ensure that onlypath...functions are used to create,manipulate file uris