aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/windows
Commit message (Collapse)AuthorAge
* Windows,JNI: more tolerance for errorsGravatar Laszlo Csomor2018-07-24
| | | | | | | | | | | | | | | | | | | | | DeletePath and CreateJunction are now even more tolerant with errors, particularly the class of errors where access is denied. Also in this change: - remove DeletePathResult::kParentMissing, as this case is handled by CreateFileW's error handling later - do not error-check CreateDirectoryW; if failed, just proceed as if the directory already existed - print more debugging info where possible Change-Id: I1162dae2c6b7524f14d8892047f9eb51831470dd Closes #5611. Change-Id: I78fe6aed6d0b120815339c0923c8a903990921d9 PiperOrigin-RevId: 205796307
* Windows,JNI: graceful error-handlingGravatar Laszlo Csomor2018-07-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CreateJunction and DeletePath are now more resilient to errors: - CreateJunction opens the junction path to check its target requesting fewer rights and with greater sharing permission. This way it can check junction targets even if the junction name is opened by another process with no sharing. - DeletePath attempts to call FindFirstFileW if GetFileAttributesW fails with ERROR_ACCESS_DENIED. There's hardly any info about this error mode online, except for a code comment in the .NET CoreFX library. (See new code comments in this commit.) Also: - Change the error codes for DeletePath. - Wrap the DeletPath error codes in a struct for better readability. Fixes https://github.com/bazelbuild/bazel/issues/5433 Change-Id: I5b6e0f27b5b22c1cf00da90104495eda84178283 Closes #5590. Change-Id: I5b6e0f27b5b22c1cf00da90104495eda84178283 PiperOrigin-RevId: 204438994
* Windows,JNI: more robust nativeCreateJunctionGravatar Laszlo Csomor2018-07-09
| | | | | | | | | | | | | | | | | | | | | | | | Rewrite the CreateJunction function in the Windows JNI library. The new implementation's improvements: - succeeds if the junction already exists with the desired target; hopefully this will fix issue https://github.com/bazelbuild/bazel/issues/5433 - tolerant to concurrent filesystem modifications, e.g. if the junction's path suddenly disappears, the function reports the error correctly Fixes https://github.com/bazelbuild/bazel/issues/5433 Change-Id: I58a2314a00f6edaa7c36c35ba54616168b44eb7d Closes #5528. Change-Id: I9f5dc9237b70a433d0d8c2578a826de3d462d110 PiperOrigin-RevId: 203744515
* vfs: fix race condition in JavaIoFileSystem.deleteGravatar Laszlo Csomor2018-07-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | JavaIoFileSystem.delete() now uses Files.deleteIfExists() to delete files and empty directories. The old code used to have a race condition: a file could have been deleted or changed to a non-directory between checking it's a directory and listing its contents. WindowsFileSystem.delete() now uses the DeletePath JNI method (wrapped by WindowsFileOperations.deletePath) which is more robust than JavaIoFileSystem.delete(), because it can delete readonly files and can tolerate some concurrent filesystem modifications. Fixes https://github.com/bazelbuild/bazel/issues/5513 Change-Id: I5d2720afff8dfd3725880a6d7408d22de5935c3d Closes #5527. Change-Id: I5d2720afff8dfd3725880a6d7408d22de5935c3d PiperOrigin-RevId: 203720575
* Move HashFunction out of FileSystem, and turn it into a class, instead of an ↵Gravatar ccalvarin2018-06-21
| | | | | | | | | enum. Now that we aren't using enum names for the hash functions, we also accept the standard names, such as SHA-256. RELNOTES: None. PiperOrigin-RevId: 201624286
* Windows: Make environment variables case-insensitive when creating Windows ↵Gravatar Yun Peng2018-05-28
| | | | | | | | | | | | process If users pass the same environment variables with different cases, the last one will override the previous ones. Fixed https://github.com/bazelbuild/bazel/issues/5285 Change-Id: Ieec857553bc54a4ad9809455687551303037e240 PiperOrigin-RevId: 198303684
* Replace path implementation.Gravatar tomlu2018-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Path and PathFragment have been replaced with String-based implementations. They are pretty similar, but each method is dissimilar enough that I did not feel sharing code was appropriate. A summary of changes: PATH ==== * Subsumes LocalPath (deleted, its tests repurposed) * Use a simple string to back Path * Path instances are no longer interned; Reference equality will no longer work * Always normalized (same as before) * Some operations will now be slower, like instance compares (which were previously just a reference check) * Multiple identical paths will now consume more memory since they are not interned PATH FRAGMENT ============= * Use a simple string to back PathFragment * No more segment arrays with interned strings * Always normalized * Remove isNormalized * Replace some isNormalizied uses with containsUpLevelReferences() to check if path fragments try to escape their scope * To check if user input is normalized, supply static methods on PathFragment to validate the string before constructing a PathFragment * Because PathFragments are always normalized, we have to replace checks for literal "." from PathFragment#getPathString to PathFragment#getSafePathString. The latter returns "." for the empty string. * The previous implementation supported efficient segment semantics (segment count, iterating over segments). This is now expensive since we do longer have a segment array. ARTIFACT ======== * Remove Path instance. It is instead dynamically constructed on request. This is necessary to avoid this CL becoming a memory regression. RELNOTES: None PiperOrigin-RevId: 185062932
* Add another path to the windows_jni.dll lookup.Gravatar Pascal Muetschard2018-01-08
| | | | | | | | | | | | | | This is to fix building android outside of the bazel repository. To reproduce the issue (on a Windows machine, of course): 1. Copy the examples/android folder from a bazel checkout to a new folder (keep the same folder structure - i.e. `<new folder>/examples/android`) 2. Create a `WORKSPACE` file in `<new folder>` with the `android_sdk_repository` and `android_ndk_repository` rules as described in the example README. 3. `bazel build examples/android/java/bazel:hello_world` 4. Observe the failure to locate `windows_jni.dll` Closes #4392. PiperOrigin-RevId: 181181641
* Automated rollback of commit 82e68b75304438c96ff878a0c2b8d18b42002486.Gravatar aehlig2017-12-19
| | | | | | | | | | | | | | Fixes #4322, #4306. *** Reason for rollback *** Introduces a deadlock (see https://github.com/bazelbuild/bazel/issues/4322) *** Original change description *** Make FileSystem operate on LocalPath instead of Path. PiperOrigin-RevId: 179549866
* Make FileSystem operate on LocalPath instead of Path.Gravatar tomlu2017-12-14
| | | | PiperOrigin-RevId: 179082062
* Move msys path support into DependencySet, removing it from the general Path ↵Gravatar tomlu2017-12-14
| | | | | | | | system. This is the only place that should actually need it. PiperOrigin-RevId: 179054861
* Add a new file path type, LocalPath.Gravatar tomlu2017-12-12
| | | | | | | | This path type is a local file path as a wrapper around a string. It works much the same as java.io.File, but without its file operations. For the most part, FilePath shouldn't add much overhead compared to using plain strings. Strings do get normalised on the way in, but no extra objects are allocated unless the path actually needs normalisation. PiperOrigin-RevId: 178798497
* Refactor the FileSystem API to allow for different hash functions.Gravatar buchgr2017-11-30
| | | | | | | | | | | | | Refactor the FileSystem class to include the hash function as an instance field. This allows us to have a different hash function per FileSystem and removes technical debt, as currently that's somewhat accomplished by a horrible hack that has a static method to set the hash function for all FileSystem instances. The FileSystem's default hash function remains MD5. RELNOTES: None PiperOrigin-RevId: 177479772
* Windows,Subcommands: argv quoting for empty argsGravatar Laszlo Csomor2017-11-14
| | | | | | | | | | | Quote empty args in the command argument vector otherwise the command's executable would not recognize them as arguments. Fixes https://github.com/bazelbuild/bazel/issues/3973 Change-Id: Iccfb59e75c748247c8df7d52fb8cf4227eae6fa7 PiperOrigin-RevId: 175672201
* Replace all usages of Blaze's Preconditions class with guava.Gravatar tomlu2017-11-09
| | | | | | | | Blaze had its own class to avoid GC from varargs array creation for the precondition happy path. Guava now (mostly) implements these, making it unnecessary to maintain our own. This change was almost entirely automated by search-and-replace. A few BUILD files needed fixing up since I removed an export of preconditions from lib:util, which was all done by add_deps. There was one incorrect usage of Preconditions that was caught by error prone (which checks Guava's version of Preconditions) that I had to change manually. PiperOrigin-RevId: 175033526
* Windows, jni: Don't close stdout/stderr in nativeWaitFor functionGravatar Yun Peng2017-10-24
| | | | | | | | | | | | | | | | | | | | | | | | These two close operations were added to work around #1708, but caused #2675. We found the root cause of the hanging problem in #1708 is a race condition when creating Windows processes: When Bazel trys to create two processes, one for a local command execution, one for starting the worker process. The worker process might accidentally inherits handles opened when creating the local command process, and it holds those handles as long as it lives. Therefore, ReadFile function hangs when handles for the write end of stdout/stderr pipes are released by the worker. The solution is to make Bazel native createProcess JNI function explicitly inheirts handles as needed, and use this function to start worker process. Related: http://support.microsoft.com/kb/315939 Fixed https://github.com/bazelbuild/bazel/issues/2675 Change-Id: I1c9b1ac3c9383ed2fd28ea92f528f19649693275 PiperOrigin-RevId: 173244832
* Add Path argument to supportsModifications, supports*LinksNatively.Gravatar tomlu2017-10-20
| | | | | | | | This works better with UnionFileSystem, as (eg.) different mapped file systems might not agree on whether they are read-only. No actual code changes have been made that actually uses this argument, so this should be a behaviour no-op. PiperOrigin-RevId: 172782759
* Move Subprocess.Factory to a top-level classGravatar ulfjack2017-09-08
| | | | | | | | | | | Also move the implementation of FutureCommandResult to a top-level class. This is in preparation for significantly simplifying the shell library. The plan is to remove the Subprocess abstraction, and have lower-level implementations implement the much simpler FutureCommandResult interface instead. PiperOrigin-RevId: 167844736
* More BUILD file refactorings.Gravatar philwo2017-09-06
| | | | | | | | | Split collect, concurrent, vfs, windows into package-level BUILD files. Move clock classes out of "util", into their own Java package. Move CompactHashSet into its own Java package to break a dependency cycle. Give nestedset and inmemoryfs their own package-level BUILD files. PiperOrigin-RevId: 167702127
* Implement timeouts on top of Java ProcessGravatar ulfjack2017-08-10
| | | | PiperOrigin-RevId: 164827022
* Rewrite the Command APIGravatar ulfjack2017-08-10
| | | | | | | | | | | | | | | | | | | | | | | | Important: the simplified API now defaults to forwarding interrupts to subprocesses. I did audit all the call sites, and I think this is a safe change to make. - Properly support timeouts with all implementations - Simplify the API - only provide two flavours of blocking calls, which require no input and forward interrupts; this is the most common usage - provide a number of async calls, which optionally takes input, and a flag whether to forward interrupts - only support input streams, no byte arrays or other 'convenience features' that are rarely needed and unnecessarily increase the surface area - use java.time.Duration to specify timeout; for consistency, interpret a timeout of <= 0 as no timeout (i.e., including rather than excluding 0) - KillableObserver and subclasses are no longer part of the public API, but still used to implement timeouts if the Subprocess.Factory does not support them - Update the documentation for Command - Update all callers; most callers now use the simplified API PiperOrigin-RevId: 164716782
* Windows: Android BusyBox can access the JNI libGravatar Laszlo Csomor2017-07-31
| | | | | | | | | | | | | | | Add a data-dependency on the windows_jni.dll from the BusyBox in BUILD.tools, so the BusyBox in @build_tools// can actually find it at runtime. Also update the script that builds the .dll so that it works if the source files have an "external/bazel_tools/" prefix. Related to https://github.com/bazelbuild/bazel/issues/3264 Change-Id: I005e9d2c00253a59d2cd5cc9f3a93528dc4d2e9e PiperOrigin-RevId: 163691320
* Windows, Android BusyBox: create JunctionCreatorGravatar Laszlo Csomor2017-07-10
| | | | | | | | | | | Introduce the JunctionCreator classes that the Android BusyBox can use to work around path length limitations on Windows. See https://github.com/bazelbuild/bazel/issues/3264 Change-Id: Ia5ee39f0635dcc2690ffb1755dc56d21e7bc7536 PiperOrigin-RevId: 161378422
* build_windows_jni.sh: move file to subdirectoryGravatar Laszlo Csomor2017-07-05
| | | | | | | | | | | | | The script more logically belongs in src/main/native/windows than in src/main/native. Also move the //src/main/native:windows_jni rule into //src/main/native/windows:windows_jni, so the logic of building the JNI library is fully contained in that package. Change-Id: I96e19003932cc0ddc5af3471b0b31a1aec09b8fa PiperOrigin-RevId: 160876594
* Windows, JNI: move around sourcesGravatar Laszlo Csomor2017-07-03
| | | | | | | | | | | | | | | | | | | | | | | | Move the Java JNI sources to a separate package: c.g.devtools.build.lib.windows.jni and c.g.devtools.build.lib.windows.runfiles. Make the native method declarations private, create public wrapper methods for them that ensure that the JNI library is loaded. Split the C++ JNI source processes.cc into two parts (processes-jni.cc and file-jni.cc), extract common functionality to jni-util.{h,cc}. This change preparse the code for Android rule support on Windows, specifically it lets the Android BusyBox use the file JNI library so it can create junctions on Windows to work around long path issues when calling external tools. See https://github.com/bazelbuild/bazel/issues/3264 Change-Id: I7f1a746d73f822ae419d11b893a91f4eb45d64da PiperOrigin-RevId: 160643355
* Automated conversion to Java 8Gravatar laurentlb2017-06-30
| | | | | | | With a few manual fixes for readability. RELNOTES: None. PiperOrigin-RevId: 160582556
* Windows, Bazel client: pass Unix root as JVM flagGravatar Laszlo Csomor2017-06-13
| | | | | | | | | | | | | The Bazel client will pass the --host_jvm_args=-Dbazel.windows_unix_root=<path> flag to the server (computed from $BAZEL_SH), and the server will no longer shell out to cygpath to compute this value. Fixes https://github.com/bazelbuild/bazel/issues/2983 Change-Id: Iacc2e2eb70eacafdf7bbcad68d375ba9eadc6ee1 PiperOrigin-RevId: 158830675
* Windows: Create a dangling junction when symlink target doesn't existGravatar Yun Peng2017-06-01
| | | | | | | | | | | | | | On Unix system, `ln -s foo bar` will create an dangling symlink bar -> foo even foo doesn't exist. The current implementation of createSymbolicLink for Windows fails in this situtation. And this lead to #2474. In this change, we create a dangling junction when the target doesn't exist which mimics the behavior on Unix. Fixed https://github.com/bazelbuild/bazel/issues/2474 Change-Id: I442ca3e2fb20b76c9b5bbfee903299fe51481f43 PiperOrigin-RevId: 157694631
* Refactor all ctor callsites of PathFragment to instead call a static ↵Gravatar nharmata2017-04-05
| | | | | | | | | | | | 'create' method. This paves the way for changing PathFragment to e.g. an abstract class with multiple subclasses. This way we can split out the windows-specific stuff into one of these concrete classes, making the code more readable and also saving memory (since the shallow heap size of the NonWindowsPathFragment subclass will hopefully be smaller than that of the current PathFragment). This also lets us pursue gc churn optimizations. We can now do interning in PathFragment#create and can also get rid of unnecessary intermediate PathFragment allocations. RELNOTES: None PiperOrigin-RevId: 152145768
* Restructure Path#getCachedChildPath to make direct method calls without ↵Gravatar nharmata2017-04-04
| | | | | | | | allocating a garbage TranslatedPath object. RELNOTES: None PiperOrigin-RevId: 152130170
* Move UnixFileSystem to lib.unix, WindowsFileSystem to lib.windowsGravatar Ulf Adams2017-02-28
| | | | | | -- PiperOrigin-RevId: 148749485 MOS_MIGRATED_REVID=148749485
* Windows: use JNI CreateJunction in Java code Gravatar Laszlo Csomor2017-02-15
| | | | | | | | | | | | | | | | Use the new CreateJunction in the Windows JNI code every time we need to create junctions. This means updating WindowsFileOperations and related tests. Add test for WindowsFileSystem.createSymbolicLink. See https://github.com/bazelbuild/bazel/issues/2238 -- Change-Id: I5827e2e70e8e147f5f102fabf95fa9a148b3bcdc Reviewed-on: https://cr.bazel.build/8896 PiperOrigin-RevId: 147598107 MOS_MIGRATED_REVID=147598107
* Windows: fix off-by-one errors with MAX_PATHGravatar Laszlo Csomor2017-02-07
| | | | | | | | | | | | | | | | | | In almost every place we compared paths against MAX_PATH, we had it wrong. MAX_PATH is the null-terminated maximum length, so paths exactly MAX_PATH long (not counting the null-terminator) were incorrectly considered short. Also fix the error message in the MSVC python wrapper, because it reported an incorrect path length limit in the warning message. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 146762382 MOS_MIGRATED_REVID=146762382
* Global cleanup change.Gravatar Googler2017-01-25
| | | | | | -- PiperOrigin-RevId: 145473478 MOS_MIGRATED_REVID=145473478
* Windows, JNI: make it work with long pathsGravatar Laszlo Csomor2017-01-16
| | | | | | | | | | | | | | When spawning a new process with CreateProcessA, convert argv0 to a 8dot3 style short path so we can support longer paths than MAX_PATH. This is the same approach we did in commit 44ecf9a0c7c25496a43f59f1c8f20df9527e12cb. See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 144613589 MOS_MIGRATED_REVID=144613589
* Windows, JNI: arg for argv0 in nativeCreateProcessGravatar Laszlo Csomor2017-01-12
| | | | | | | | | | | | | | | | | | | Add a separate argument to nativeCreateProcess for argv[0] specifically, and another for the rest of the args. In a subsequent change I'll add code to compute the 8dot3 style short name of the argv[0] so we can use longer paths for executables in CreateProcessA than we normally could. This is the same approach as used in commit 44ecf9a0c7c25496a43f59f1c8f20df9527e12cb See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 144311562 MOS_MIGRATED_REVID=144311562
* Windows: remove test-specific JNI loaderGravatar Laszlo Csomor2017-01-12
| | | | | | | | | | WindowsJniLoader.loadJniForTesting is just a special case of what WindowsJniLoader.loadJni already does, so we can just use the latter. -- PiperOrigin-RevId: 144224388 MOS_MIGRATED_REVID=144224388
* Windows: resolve shortened pathsGravatar Laszlo Csomor2017-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TL;DR: resolve "C:/progra~1" style paths, don't cache failed resolutions in the parent's Path.children When creating WindowsPath objects, resolve the "C:/progra~1" style paths to "C:/program files". This enables us to correctly compare paths on Windows. Without this canonicalization we incorrectly determine "C:/progra~1" and "C:/program files" to be different when they are actually the same. We only attempt to resolve such paths if the name looks like it's an abbreviated path. If resolution fails, probably due to the path not existing, then we don't cache this Path object in the parent's `children` list. This avoids stale cache entries in case the path springs into existence later in the server's lifetime. Fixes https://github.com/bazelbuild/bazel/issues/2145 We also need to rectify https://github.com/bazelbuild/bazel/issues/2173 -- PiperOrigin-RevId: 143442134 MOS_MIGRATED_REVID=143442134
* Load JNI library on Windows from the runfiles tree as a fallbackGravatar Damien Martin-Guillerez2016-12-28
| | | | | | | | | | | | | | | | | This is the behavior of the UnixJniLoader. In order to do that, this change also moved the runfiles support on Windows in its own library that the WindowsJniLoader can use to load the JNI library from tests. Also add the JNI library on Windows to all test that use the JNI library on Unix. Fixes #2300. -- Change-Id: I2eb9207c3aa310d95912a48f64f676957c47cd34 Reviewed-on: https://cr.bazel.build/8045 PiperOrigin-RevId: 143114397 MOS_MIGRATED_REVID=143114397
* Windows JNI: ensure JNI is loaded for getLongPathGravatar Laszlo Csomor2016-12-21
| | | | | | -- PiperOrigin-RevId: 142670226 MOS_MIGRATED_REVID=142670226
* Windows, JNI: implement nativeGetLongPathGravatar Laszlo Csomor2016-12-15
| | | | | | | | | | | | | | | | | | | | Implement a JNI method that can resolve 8dot3 style paths. This is necessary because we need to be able to compare 8dot3 style paths and long paths [1], and because implementing this correctly in Java seems to be impossible [2]. This change also adds tests for the JNI isJunction implementation. See https://github.com/bazelbuild/bazel/issues/2101 [1] https://github.com/bazelbuild/bazel/issues/2145 [2] https://github.com/bazelbuild/bazel/issues/2145#issuecomment-266766716 -- PiperOrigin-RevId: 142123750 MOS_MIGRATED_REVID=142123750
* Windows JNI library: prepare for widechar WinAPIGravatar Laszlo Csomor2016-12-06
| | | | | | | | | | | | | | | | | | This change: - renames windows_error_handling.* to windows_util.* - moves most stuff except for the JNI method implementations into the new windows_util namespace - implements a jstring to wchar string converter - uses GetFileAttributesW in windows_file_operations.cc See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 141187291 MOS_MIGRATED_REVID=141187291
* Fixed a bug during bootstrapGravatar Yun Peng2016-09-08
| | | | | | | | | Fixed #1732 RELNOTES: -- MOS_MIGRATED_REVID=132436686
* Windows, JNI: implement native isJunction method.Gravatar Laszlo Csomor2016-09-06
| | | | | | | WindowsFileSystem.java does not yet use it. -- MOS_MIGRATED_REVID=132043739
* Windows, JNI: do not load windows_jni.dll twice.Gravatar Laszlo Csomor2016-08-31
| | | | | | | | | WindowsProcesses.ensureJni() was duplicating the work of WindowsJniLoader.loadJni(); this change removes the former and replaces the only call site with the latter. -- MOS_MIGRATED_REVID=131806917
* Implement timeouts on Windows.Gravatar Lukacs Berki2016-08-22
| | | | | | | Makes #1664 much less acute. -- MOS_MIGRATED_REVID=130750731
* Fix capturing stdin/stdout on Windows.Gravatar Dmitry Lomov2016-07-11
| | | | | | | | | | | 1. Return EOF for streams representing Windows process pipes. 2. Fix the timing of process.close() 3. Un-synchronized reading of stderr and stdout. -- Change-Id: Iec98f45db9984be2c2b066962801cbd3ca60da3f Reviewed-on: https://bazel-review.googlesource.com/#/c/4000/ MOS_MIGRATED_REVID=126910063
* Propagate the system root to every process created in WindowsSubprocessFactory.Gravatar Lukacs Berki2016-07-07
| | | | | | | | | | | This is apparently required by some versions MSVCRT.DLL including the one used in the CL.EXE we happen to be using for testing. This was learned by reading the source code of OpenJDK. Fixes #1480. -- MOS_MIGRATED_REVID=126786461
* Make Windows process management nicer.Gravatar Lukacs Berki2016-07-06
| | | | | | | | | Subprocesses now get killed if the Bazel server itself is killed and so do their subprocesses. Also implemented Subprocess#close() so that we get a little more control over when the native structures are cleaned up. -- MOS_MIGRATED_REVID=126628000
* Use the subprocess factory that uses the Win32 API on Windows.Gravatar Lukacs Berki2016-07-04
| | | | | | | We should really do something about the mess that is loading our JNI libraries -- io.bazel.EnableJNI is mentioned eight times in the code in various diverse contexts. This change is not the right place to do it, though. -- MOS_MIGRATED_REVID=126570481
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-20 07:14:34 +0000