aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/cpp/util/file_platform.h
Commit message (Collapse)AuthorAge
* Windows: Native launcher now works with unicode.Gravatar Yun Peng2018-06-25
| | | | | | | | | | | | | | The native launcher can now launch Java and Bash binary in directory with non-English characters. Unfortunately, python doesn't support running python zip file under directory with non-English characters. eg. python ./??/bin.zip will still fail. See https://github.com/bazelbuild/bazel/issues/4473 Change-Id: I77fe9cdaabffc2e0d25c7097da5c0c9333a9c4a3 PiperOrigin-RevId: 201939391
* Windows,Bazel client: check embedded tools fasterGravatar Laszlo Csomor2018-06-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | The Bazel client on Windows is now 50% faster to check the embedded tools than it was before. Results: - Linux: 20 ms -> 6 ms - Windows: 294 ms -> 133 ms Measurements were done with n=10 runs and a hot server, using blaze::GetMillisecondsMonotonic(). Previously the client performed the same tasks multiple times while trying to determine if a path was a good extracted binary. (E.g. converted the path to Windows format multiple times, checked if it was a directory twice, opened the path twice.) Now the client performes these tasks only once, e.g. it converts path once and stats only once. See https://github.com/bazelbuild/bazel/issues/5444 Closes #5445. PiperOrigin-RevId: 201913758
* Remove usage of COMPILER_MSVC in Bazel and ijarGravatar Loo Rong Jie2018-06-11
| | | | | | | | | | | | | Convert most `COMPILER_MSVC` to `_WIN32` (as they apply to Windows platform, not MSVC compiler). Only `src/tools/singlejar/zip_headers.h` and `src/main/cpp/util/md5.h` actually need `_MSC_VER`. `COMPILER_MSVC` in `third_party/protobuf` are not removed. They can be fixed by updating dependency to newer version. /cc @meteorcloudy Closes #5350. Change-Id: Ibc131abfaf34a0cb2bd338549983ea9d28eaabfe PiperOrigin-RevId: 200019793
* Move path-manipulation functions to own library file.Gravatar ccalvarin2018-06-05
| | | | | | | | | | | Leave functions that make file accesses in the file library, and general blaze utilities in the blaze_util file, but move the functions that boil down to string manipulation and path formatting to their own file. (With the exception of getCWD, since absolute path syntax is relevant here.) Doing this largely to consolidate all Windows path control into a single place, so that it's easier to notice inconsistencies. For instance, ConvertPath currently makes Windows paths absolute, but not Posix paths, and MakeAbsolute relies on this behavior. In addition, JoinPath assumes Posix path syntax, which leads to some odd looking paths. These will be fixed in a followup change. (Found these issues while working on #4502, trying to fix the windows-specific system bazelrc.) RELNOTES: None. PiperOrigin-RevId: 199368226
* windows,client: fix error reportingGravatar Laszlo Csomor2018-04-24
| | | | | | | | | | | | | | | | | | | | | | Fix error reporting in the path conversion methods of the Bazel client. Previously the error reporting logic used GetLastErrorString in places where it was not appropriate (i.e. it was not a failed Windows API call that caused an error). This cleanup prepares removing the concept of the MSYS root from the Bazel client, since MSYS paths are no longer supported and we want to cut Bazel's dependency on Bash (thus MSYS) completely. See https://github.com/bazelbuild/bazel/issues/4319 Change-Id: Ie50a20e0ee0c572592f637340a2f2948c7f53088 Closes #5072. Change-Id: Ie50a20e0ee0c572592f637340a2f2948c7f53088 PiperOrigin-RevId: 194052665
* Windows, Java launcher: Use relativize paths in classpath jarGravatar Yun Peng2018-01-11
| | | | | | | Fixed https://github.com/bazelbuild/bazel/issues/4408 Change-Id: Id62b25e675822bbed91a448e70bdcb76e722721e PiperOrigin-RevId: 181591585
* Include <cinttypes> instead of <stdint.h>Gravatar Damien Martin-Guillerez2017-07-27
| | | | | | | | | | | cinttypes is the C++ header that should replace stdint.h. Not using the correct header was leading to compilation error on CentOS 6.7 Fixes #3455. To be cherry-picked for #3375. Change-Id: I6df22134a4a4902ec9fa7ecdfaeb5408eacf3564 PiperOrigin-RevId: 163334651
* Bazel client: add blaze_util::IsDevNullGravatar Laszlo Csomor2017-07-25
| | | | | | | | | | | | | | | | | | | | | | Add a method to test if a path is /dev/null (or case-insensitive "NUL" on Windows), and use it in blaze::MakeAbsolute. In this commit: - implement blaze_util::IsDevNull with POSIX and Windows semantics + add tests - blaze::MakeAbsolute calls blaze::ConvertPath on its input to convert MSYS paths on Windows - blaze_util::GetCwdW (thus GetCwd) always returns a lowercase path so that it is deterministic - blaze_util::GetCurrentDrive returns lowercase letter to be consisent with blaze::ConvertPath, which also returns a lowercase path Fixes https://github.com/bazelbuild/bazel/issues/3440 Change-Id: I3af5ba0a033d542fe64a676d67f27472298d1089 PiperOrigin-RevId: 163038503
* Windows: add blaze_util::AsAbsoluteWindowsPathGravatar laszlocsomor2017-07-24
| | | | | | | | | | | Replace blaze_util::AsWindowsPathWithUncPrefix with AsAbsoluteWindowsPath, which always returns an absolute path. Fixes https://github.com/bazelbuild/bazel/issues/2935 RELNOTES: none PiperOrigin-RevId: 162727218
* Don't set the +x bit by default on WriteFile().Gravatar lberki2017-06-27
| | | | | | | This change is a spiritual successor of https://bazel-review.googlesource.com/c/7410/ . That one had a merge conflict and it was small enough that a rewrite was easier than updating it. RELNOTES: None. PiperOrigin-RevId: 160251282
* Bazel client: simplify ReadDirectorySymlinkGravatar laszlocsomor2017-03-31
| | | | | | | | | | | | | | | This is a bugfixed version of https://cr.bazel.build/9520 which broke some Google-internal tests. This change allows removing duplicate code: ReadDirectorySymlink was implemented on Windows as a junction resolver, which is also implemented in file_windows.cc. Now it uses the JunctionResolver. RELNOTES: none PiperOrigin-RevId: 151691895
* Bazel client, Windows: CreateDirectoryW path limitGravatar Laszlo Csomor2017-03-09
| | | | | | | | | | | | | | | Fix the path limit for non-UNC-prefixed paths when using CreateDirectoryW. According to MSDN [1], this is only 248 chars, as opposed to the usual 260 (MAX_PATH). See https://github.com/bazelbuild/bazel/issues/2107 [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa363855(v=vs.85).aspx -- PiperOrigin-RevId: 149627964 MOS_MIGRATED_REVID=149627964
* Bazel client, Windows: fix AsShortWindowsPathGravatar Laszlo Csomor2017-03-06
| | | | | | | | | | This method now works for non-existent paths too. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 149284633 MOS_MIGRATED_REVID=149284633
* Bazel client: fix broken compilation Gravatar Laszlo Csomor2017-03-02
| | | | | | | | | | | | | | | | Do not include <windows.h> in file_platform.h because it #defines many symbols that later code, particularly function definitions, conflict with, e.g. GetUserName, SendMessage. This was breaking the Bazel bootstrap project on CI. -- Change-Id: Ie4b59b00fc617bd3e7d0cbb967c1232798e055de Reviewed-on: https://cr.bazel.build/9127 PiperOrigin-RevId: 148986922 MOS_MIGRATED_REVID=148986922
* Bazel client: do not use `errno`.Gravatar Laszlo Csomor2017-03-02
| | | | | | | | | | | | | | | Do not use `errno` in platform-independent code, because Windows API functions don't set it. This change abstracts away error handling and the functions whose `errno` result we care about, will set an input error variable. Fixes https://github.com/bazelbuild/bazel/issues/2506 -- PiperOrigin-RevId: 148977873 MOS_MIGRATED_REVID=148977873
* Bazel client: simplify {Read,Write}File semanticsGravatar Laszlo Csomor2017-03-01
| | | | | | | | | | | | | | | | Introduce a platform-specific file handle type (HANDLE on Windows, int on Linux/Darwin/FreeBSD) so we can get rid of the read_func and write_func functions, since they are always the same everywhere. Also include file_platform.h in file.h, since they are logically the same file (file_platform.h is just the platform-specific part of file.h). -- PiperOrigin-RevId: 148892736 MOS_MIGRATED_REVID=148892736
* Bazel client: add new ReadFile/WriteFile variantsGravatar Laszlo Csomor2017-02-27
| | | | | | | | | | | | | Instead of writing from / reading to a string, these variants take a buffer and a size. These methods will be used from ijar. See https://github.com/bazelbuild/bazel/issues/2157 -- PiperOrigin-RevId: 148635487 MOS_MIGRATED_REVID=148635487
* Bazel client: retry moving install base directoryGravatar Laszlo Csomor2017-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | Do not give up immediately if renaming/moving the install base directory fails, wait and retry instead. This is necessary because on Windows the directory we just created and populated with the extracted embedded binaries may still be scanned by the antivirus, so there are open file handles in it so it cannot be renamed. This new logic ensures the AV has enough time to scan all files, close the handles, letting us successfully rename the directory. Fixes the occasional "install base directory cannot be renamed in place" error messages on Windows. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 146899919 MOS_MIGRATED_REVID=146899919
* Rollback of commit 855fbe9ee447b7b37fd8c73dbc047d69b7ceffcf.Gravatar Yun Peng2017-02-01
| | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Causing bazel server restart every time on Windows See https://github.com/bazelbuild/bazel/issues/2466 *** Original change description *** Bazel client: platform-specific JoinPath This allows joining paths on "\" instead of "/" when building for Windows. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 146246700 MOS_MIGRATED_REVID=146246700
* Bazel client: platform-specific JoinPath Gravatar László Csomor2017-01-30
| | | | | | | | | | | | | This allows joining paths on "\" instead of "/" when building for Windows. See https://github.com/bazelbuild/bazel/issues/2107 -- Change-Id: I417ba40af6530650be2394db4bd445f0883d40e5 Reviewed-on: https://cr.bazel.build/8495 PiperOrigin-RevId: 145961689 MOS_MIGRATED_REVID=145961689
* Bazel client: abstract away mtime handlingGravatar Laszlo Csomor2017-01-19
| | | | | | | | | | | | | | | | | | | | | Create an IFileMtime class and platform-specific implementations to deal with mtime handling. Since epochs and time granularity vary from platform to platform, and we only care about setting a file's/directory's mtime to the current time or to a future time plus querying whether something is in the future, we can easily create an interface for these operations and that's exactly what IFileMtime is. Implement PosixFileMtime and WindowsFileMtime. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 144956966 MOS_MIGRATED_REVID=144956966
* Bazel client, Windows: use CreateFileWGravatar Laszlo Csomor2017-01-18
| | | | | | | | | | | | | | | | | | | | | | Use CreateFileW in blaze_util_windows.cc when opening the "jvm.out" file. This allows supporting long paths. Also use AsWindowsPathWithUncPrefix instead of just AsWindowsPath plus manually adding the UNC prefix. Also fix a compilation error in file_windows_test.cc, I'm surprised the CI system didn't catch this, maybe we aren't running this test there. See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 144813245 MOS_MIGRATED_REVID=144813245
* Bazel client: split CanAccess to specific methodsGravatar Laszlo Csomor2017-01-11
| | | | | | | | | | | | | | The new methods (CanReadFile, CanExecuteFile, CanAccessDirectory) are a lot easier to implement on Windows than a generic CanAccess. On POSIX these methods are just a wrapper around the now static-visible CanAccess(). See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 144176710 MOS_MIGRATED_REVID=144176710
* Windows: implement and use AsShortWindowsPathGravatar Laszlo Csomor2017-01-10
| | | | | | | | | | | | | | | | | | Because CreateProcessW doesn't support long paths, not even with the "\\?\" prefix [1], we need to convert long paths to short ones to spawn processes. This change implements the corresponding function and uses it in blaze_util_windows. [1] https://github.com/bazelbuild/bazel/issues/2181#issuecomment-270696173 See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 144062404 MOS_MIGRATED_REVID=144062404
* Bazel client: move NormalizePath to Windows codeGravatar Laszlo Csomor2017-01-10
| | | | | | | | | | | | | | | | | | | | | | | | | | This method was only used by the Windows-specific code so move it there and adapt it to Windows paths. Update AsWindowsPath to normalize its output: this is necessary because AsWindowsPath's output is a widechar path string which we often prefix with the UNC prefix, but such paths must be normalized (the kernel won't do it if the path has an UNC prefix). Finally, add an AsWindowsPathWithUncPrefix method which does what the name suggests: converts the path to Windows path, makes it absolute, and adds the UNC prefix if necessary. (This is a very common operation when calling WinAPI functions and we'll use it a lot in subsequent changes.) See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 144060297 MOS_MIGRATED_REVID=144060297
* Bazel client: implement PathExists on WindowsGravatar Laszlo Csomor2017-01-05
| | | | | | | | | | | | | | | | | | | | Checking if a path exists is surprisingly hard on Windows. The most convenient API functions are PathFileExists and GetFileAttributes but neither of them follows junctions. To check if a junction is dangling, we have to resolve it all the way. This change adds a JunctionResolver class to file_windows, which can resolve junctions (if they aren't dangling) and non-junctions (in this case just checks their existence). See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 143645274 MOS_MIGRATED_REVID=143645274
* Bazel client: add comments, delete dead codeGravatar Laszlo Csomor2016-12-22
| | | | | | | | | | In this change: - add TODOs and comments - inline blaze::ExitImmediately at call sites -- PiperOrigin-RevId: 142671757 MOS_MIGRATED_REVID=142671757
* Bazel client: remove blaze_util::WhichGravatar Laszlo Csomor2016-12-21
| | | | | | | | | This is only used in blaze_util_linux so move the method there. -- PiperOrigin-RevId: 142652521 MOS_MIGRATED_REVID=142652521
* Bazel client, Windows: implement AsWindowsPathGravatar Laszlo Csomor2016-12-20
| | | | | | | | | | | | | | | | | | | | This method converts MSYS paths to Windows path. It uses the BAZEL_SH envvar to obtain the MSYS root directory, to which all Unix paths (except for mounts) are relative. We cannot handle mounts because we don't want to read /etc/mtab every time there's a file operation so we simply apply a heuristic similar to https://github.com/bazelbuild/bazel/blob/cd4cc09fa6ef96380a3d0888f825dfd1dbada651/src/main/java/com/google/devtools/build/lib/vfs/WindowsFileSystem.java#L52-L63 Also clean up the #ifdefs surrounding SyncFile. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 142531986 MOS_MIGRATED_REVID=142531986
* Bazel client: generalize path handlingGravatar Laszlo Csomor2016-12-19
| | | | | | | | | | | | | | Use/implement utility methods to join paths, check if they are the root directory or are absolute, etc. Doing so (instead of say checking if a path starts with "/") allows for correct behavior on Windows. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 142446027 MOS_MIGRATED_REVID=142446027
* Bazel client: SplitPath works with Windows pathsGravatar Laszlo Csomor2016-12-19
| | | | | | | | | | | This allows correct behavior of Dirname and Basename on Windows. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 142441234 MOS_MIGRATED_REVID=142441234
* move MakeDirectories() into file_platform.hGravatar Thiago Farina2016-12-07
| | | | | | | | | | | | | | This way we can remove the dependency on blaze_util (which is Bazel's client specific) from singlejar. This work was made possible by commit 49970e0136d0: ("Bazel client: platform-specific {Read,Write}File"). -- Change-Id: I6e95fb9119a271e4d48cbe2eefc1d5354ee188aa Reviewed-on: https://cr.bazel.build/7650 PiperOrigin-RevId: 141294165 MOS_MIGRATED_REVID=141294165
* Add missing <time.h> include.Gravatar Piotr Sikora2016-12-05
| | | | | | | | Fixes build on FreeBSD 11. -- PiperOrigin-RevId: 141029578 MOS_MIGRATED_REVID=141029578
* Bazel client: platform-specific {Read,Write}FileGravatar Laszlo Csomor2016-11-28
| | | | | | | | | | | | | | | | Move blaze::ReadFile and blaze::WriteFile to file.h and file_platform.h (thus into the blaze_util namespace), and update references. This allows us to implement these methods in a platform-specific way. Also move UnlinkPath. See https://github.com/bazelbuild/bazel/issues/2107 -- MOS_MIGRATED_REVID=140328273
* Bazel client: MakeCanonical into file_<platform>Gravatar Laszlo Csomor2016-11-24
| | | | | | | | | | | | Move MakeCanonical into platform-specific files. Also change the signature of blaze.cc:CheckBinaryPath to return the binary path instead of mutating `globals`. See https://github.com/bazelbuild/bazel/issues/2107 -- MOS_MIGRATED_REVID=140128173
* Bazel client: create a wrapper around Unix pipesGravatar Laszlo Csomor2016-11-18
| | | | | | | | | This allows implementing pipe-handling in a platform-specific way. Windows also supports pipes but through its own API. -- MOS_MIGRATED_REVID=139564316
* Bazel client: reduce dependency on <unistd.h>Gravatar Laszlo Csomor2016-11-18
| | | | | | | | | | | | | | | | | | In this change: - rename WriteFileToStreamOrDie to WriteFileToStderrOrDie (since we only ever used it for stderr) - replace open/write/read/close operations with blaze_util::ReadFile/WriteFile - wrap ToString(getpid()) in a utility function - move SyncFile to file_<platform> -- MOS_MIGRATED_REVID=139560397
* Bazel client: no longer needs <utime.h>Gravatar Laszlo Csomor2016-11-17
| | | | | | | | | | | | Also remove a lot of unused header files. The only remaining header file not available on Windows is <unistd.h>, but cutting that dependency will be more complicated because we use read/write and similar I/O functions from it. -- MOS_MIGRATED_REVID=139439791
* Bazel client: no more `stat` usageGravatar Laszlo Csomor2016-11-17
| | | | | -- MOS_MIGRATED_REVID=139436876
* Bazel client: implement directory tree walkingGravatar Laszlo Csomor2016-11-16
| | | | | | | | | | | | | | | | | | | | | | This change: - merges the //src/{main,test}/cpp:file and //src/{main,test}/cpp:file_platform libraries because "file" and "file_platform" need each other and this makes logical sense anyway - implements a function in file_<platform> to run a custom function on every child of a directory - implements a function in file.cc to recursively traverse a directory tree, based on the previosly mentioned function - removes the corresponding logic from the Bazel client to make it more portable -- MOS_MIGRATED_REVID=139309562
* Bazel client: wrap some POSIX functionsGravatar Laszlo Csomor2016-11-10
| | | | | | | | | | | | | | This change: - starts using blaze_util::CanAccess and blaze_util::PathExists instead of access(2) - implements and starts using blaze_util::GetCwd instead of getcwd(2) - implements and starts using blaze_util::ChangeDirectory instead of chdir(2) - adds tests for the new wrapper methods -- MOS_MIGRATED_REVID=138750297
* blaze_utils: fork file handling for platformsGravatar Laszlo Csomor2016-11-09
This commit repurposes file_posix.cc to be the POSIX API file handling implementation, and adds file_windows.cc for the Win32 API implementations. Furthermore it introduces file_platform.h that declares the interface. Subsequent changes will replace POSIX API calls in the rest of the C++ code with these abstract methods. Motivation: our code is so littered with POSIX-isms that we need an abstraction layer if we hope to compile it with MSVC. -- MOS_MIGRATED_REVID=138615822
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-02 23:54:45 +0000