aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/unix/UnixFileSystem.java
Commit message (Collapse)AuthorAge
* Automated rollback of commit 80c8ff1819a889814cbe2dae477d7fedce6aa181.Gravatar tomlu2018-01-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Rolling forward after underlying issue has been fixed. *** Original change description *** Automated rollback of commit d50cbbeef115f28c0cea1ac17572e0f12c0cf312. *** Reason for rollback *** b/71442447 *** Original change description *** Remove synchronization from file system. After the path refactor we will no longer have path instances to synchronize on. The underlying OS file systems are already naturally thread safe, that is, their internal data structures cannot be damaged. Any further synchronization (eg. races between directory creation and deletion) has to be managed at the client level. The l... *** PiperOrigin-RevId: 181368707
* Automated rollback of commit d50cbbeef115f28c0cea1ac17572e0f12c0cf312.Gravatar tomlu2018-01-05
| | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** b/71442447 *** Original change description *** Remove synchronization from file system. After the path refactor we will no longer have path instances to synchronize on. The underlying OS file systems are already naturally thread safe, that is, their internal data structures cannot be damaged. Any further synchronization (eg. races between directory creation and deletion) has to be managed at the client level. The last attempt to do this failed because of races in FileUtils#createDirectoryAndParents on Windows. This method is now gone, rep... *** ROLLBACK_OF=180290901 PiperOrigin-RevId: 180936132
* Remove synchronization from file system.Gravatar tomlu2017-12-28
| | | | | | | | | | After the path refactor we will no longer have path instances to synchronize on. The underlying OS file systems are already naturally thread safe, that is, their internal data structures cannot be damaged. Any further synchronization (eg. races between directory creation and deletion) has to be managed at the client level. The last attempt to do this failed because of races in FileUtils#createDirectoryAndParents on Windows. This method is now gone, replaced by a method from the Java framework that knows how to synchronize. PiperOrigin-RevId: 180290901
* Add FileSystem#createDirectoryAndParents.Gravatar tomlu2017-12-21
| | | | | | | | A native implementation of this (instead of using FileSystemUtils, which can only use public interfaces) should be more efficient and more easy to make correct. In particular, it should allow removing FileSystemUtils#createDirectoriesAndParents, which has poor thread safety characteristics. The latter method has a lot of logic that forces certain unnatural atomicity guarantees on createDirectory, and it also has logic that is conditional on sub-string content of exception messages. PiperOrigin-RevId: 179819623
* 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
* Thread FileSystem instance through a few call sites.Gravatar tomlu2017-12-11
| | | | PiperOrigin-RevId: 178704585
* Thread filesystem through codebase.Gravatar tomlu2017-12-08
| | | | | RELNOTES: None PiperOrigin-RevId: 178426166
* 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
* 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
* Change FileSystem#getDirectoryEntries to return strings of the ↵Gravatar tomlu2017-10-23
| | | | | | | | file/directory names instead of paths. This is a small isolated change that can be done ahead of the big refactoring. PiperOrigin-RevId: 173124518
* 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
* Adding support for SHA256 for remote execution. Switch remote execution to useGravatar olaola2017-06-20
| | | | | | | | | the currently defined hash function for blobs. Some refactoring. Adding an option to set the hash function in the remote worker, defaulting to the current behavior (unfortunately it is a build option, have not found a clean way to specify it at runtime). BUG=62622420 TESTED=remote worker RELNOTES: none PiperOrigin-RevId: 159473116
* 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
* Move UnixFileSystem to lib.unix, WindowsFileSystem to lib.windowsGravatar Ulf Adams2017-02-28
-- PiperOrigin-RevId: 148749485 MOS_MIGRATED_REVID=148749485
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-06 09:27:20 +0000