| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 179748374
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 179082062
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Break CI Windows nightly build: https://github.com/bazelbuild/bazel/issues/3927
https://ci.bazel.io/blue/organizations/jenkins/Global%2Fbazel-tests/detail/bazel-tests/314/pipeline/31
*** Original change description ***
Remove synchronization from FileSystem implementations.
PiperOrigin-RevId: 173243523
|
|
|
|
| |
PiperOrigin-RevId: 171905267
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was previously in unix, but also used from non-unix file systems, which
means it's not actually unix-specific. This is in preparation for splitting
compilation of the unix and windows file systems into separate libraries.
That improves layering and reduces compile times - note that Bazel already
injects the vfs into its lower layers, which should only rely on the normal
vfs APIs, not on anything platform-specific.
--
PiperOrigin-RevId: 147829659
MOS_MIGRATED_REVID=147829659
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AbstractFileSystem.getFile{Input,Output}Stream
created anonymous File{Input,Output}Stream
objects. These hold a reference to the outer class
instance (AbstractFileSystem). This may prevent
memory release in case the returned objects are
kept around even if the AbstractFileSystem
instance could otherwise be released.
This particular refactoring is unlikely to have
caught any memory leaks like this, so it's not
really necessary, but I came across it and thought
it won't hurt and will future-prove the class
against such leaks.
--
MOS_MIGRATED_REVID=137254192
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=128476121
|
|
|
|
|
|
|
|
|
| |
(accidentally) the implicit requirement that the deriving class override FileSystem#stat.
Even though this wasn't a problem in practice in the Bazel codebase (since all of our transitive subclasses had custom 'stat' implementation), it's good hygiene to have things correct (e.g. if we added a new subclass).
--
MOS_MIGRATED_REVID=108158039
|
|
|
|
|
|
|
| |
FileStatus#isSpecialFile to help disambiguate between a regular file and a special file, since the file size of a special file cannot be trusted.
--
MOS_MIGRATED_REVID=105903622
|
|
|
|
|
|
|
|
|
| |
helper classes do call that method to see if the stream has more data.
This is part of a series of changes with the net result being that we open, read, and parse each BUILD file exactly once.
--
MOS_MIGRATED_REVID=105253425
|
|
|
|
|
|
|
|
|
|
|
| |
The headers were modified with
`find . -type f -exec 'sed' '-Ei' 's|Copyright 201([45]) Google|Copyright 201\1 The Bazel Authors|' '{}' ';'`
And manual edit for not Google owned copyright. Because of the nature of ijar, I did not modified the header of file owned by Alan Donovan.
The list of authors were extracted from the git log. It is missing older Google contributors that can be added on-demand.
--
MOS_MIGRATED_REVID=103938715
|
|
--
MOE_MIGRATED_REVID=85702957
|