As per https://github.com/facebook/watchman/wiki/Better-Unicode-handling-plan.

• Added tests specific to BSER v1 (to make sure things don't break during the transition).
• Renamed STRING to BYTESTRING.
• Added context type for switching BSER versions.
• Added BSER version switching logic to server.
• Added BSER v2 as a capability testable with the version command.
• Added logic for negotiating up to BSER v2 if both client and server support it.

@wez edited this issue to place this status at the top

Current status: Alpha for 64-bit Windows. It builds and passes the test suite on Windows Server 2012 R2 (x64) and should work on Windows 7 and later. PCRE expression terms are not currently supported.

At this time we're looking for alpha testers. Watchman on Windows may hang, crash or otherwise be unreliable. If you encounter problems we'll need you to provide detailed information about how to trigger the problem, and we may ask you to use visual studio to attach and perform some rudimentary debugging.

The latest build is available here: https://ci.appveyor.com/api/projects/wez/watchman/artifacts/watchman.zip?branch=master&job=Environment:+WATCHMAN_WIN7_COMPAT%3D

Extract the zip file and make sure that watchman.exe is located in your PATH. The watchman.pdb file is provided to facilitate debugging.

If you are consuming watchman from python, you will need to build pywatchman for yourself. The released package on https://pypi.python.org/pypi/pywatchman should work for this purpose.

If you are consuming watchman from nodejs, the existing fb-watchman package available via npm should work, but the version in master has slightly better diagnostics in case you experience hangs.

Test Plan:

Ran locally using this

travis_cache_dir=/tmp/travis-ccache gcc_version=5 os_image=ubuntu:16.04 ./build/fbcode_builder/travis_docker_build.sh

and will let our CI process it now.

This doesn't change travis to use the fbcode builder docker bits.

Hi,

I'm facing a bug with watchman. Whenever I'm starting watchman and sending a command (such as watchman watch-list or event watchman version or creating a trigger, it's getting stuck. watchman --help & watchman -v work though.

I've been using watchman for months without troubles. Yesterday I've enabled filevault on my mac and I upgraded watchman to 4.7.0 using brew. I've reinstalled 4.6.0 from the sources, I'm observing the same problem.

Any advices on how I could provide you more info / logs on this issue ?

Regards,

Florent

Hey,

I've grabbed the latest watchman from https://ci.appveyor.com/api/projects/wez/watchman/artifacts/watchman.zip?branch=master&job=Environment:+WATCHMAN_WIN7_COMPAT%3D

React-native version: 0.44.2 (latest) Windows 10

Running react-native with react-native start

Looking for JS files in
   C:\tmp\test\test


React packager ready.

Loading dependency graph, done.
error: bundling: Error
    at DependencyGraph._getAbsolutePath (C:/tmp/test/test/node_modules/react-native/packager/src/node-haste/index.js:272:11)
    at DependencyGraph.getDependencies (C:/tmp/test/test/node_modules/react-native/packager/src/node-haste/index.js:216:26)
    at Resolver.getDependencies (C:/tmp/test/test/node_modules/react-native/packager/src/Resolver/index.js:106:27)
    at _resolverPromise.then.resolver (C:/tmp/test/test/node_modules/react-native/packager/src/Bundler/index.js:561:62)
    at process._tickCallback (internal/process/next_tick.js:109:7)
Bundling `index.android.js`  0.0% (0/1), failed.

React native on device gives the following error Cannot find entry file index.android.js in any of the roots ["c:/tmp/test/test/"]

Watchman logs

2017-06-05T09:27:39,625: [listener] Watchman 4.9.0 <no build info set> starting up on NTCSRF206
2017-06-05T09:27:39,632: [listener] failed to parse json from C:\Users\Matt\AppData\Local\Temp/Matt-state/state: unable to open C:\Users\Matt\AppData\Local\Temp/Matt-state/state: No such file or directory
2017-06-05T09:27:39,632: [listener] waiting for pipe clients on \\.\pipe\watchman-Matt
2017-06-05T09:27:39,656: [client=000001D8D9454810:stm=000001D8D9452770:pid=0] path C:/tmp/test/test is on filesystem type NTFS
2017-06-05T09:27:39,658: [client=000001D8D9454810:stm=000001D8D9452770:pid=0] root C:/tmp/test/test using watcher mechanism win32 (auto was requested)
2017-06-05T09:27:41,398: [client=000001D8D9454810:stm=000001D8D9452770:pid=0] PERF: {"start_time": 1496620659.6559999, "version": "4.9.0", "description": "dispatch_command:watch-project", "meta": {"root": {"path": "C:/tmp/test/test", "watcher": "win32", "ticks": 1, "recrawl_count": 0, "case_sensitive": false, "number": 1}, "args": ["watch-project", "C:/tmp/test/test"], "client": {"pid": 0}}, "pid": 12892, "elapsed_time": 1.742}
2017-06-05T09:27:41,398: [io 000001D8D946DC10 C:/tmp/test/test] crawl complete
2017-06-05T09:27:41,398: [io 000001D8D946DC10 C:/tmp/test/test] PERF: {"start_time": 1496620659.6689999, "version": "4.9.0", "description": "full-crawl", "meta": {"root": {"path": "C:/tmp/test/test", "watcher": "win32", "ticks": 2, "recrawl_count": 0, "case_sensitive": false, "number": 1}}, "pid": 12892, "elapsed_time": 1.7290000000000001}

I can confirm watchman 4.7.0 worked (though it had the symlink issue on windows)

Thanks, I'm currently digging through RN code trying to see if I can find anything...

In looking at the next generation index stuff, I wanted to define type safe vectors, maps and sets so that we can have the compiler catch any silly mistakes as the code becomes more complex.

I took a stab at doing something with macros and inline functions in C for vectors (the simplest container) and realized that by the time that I would have been able to apply this to the other container types, I would have basically implemented C++ in C, and done it poorly.

So, this PR is the most basic C -> C++11 translation: the very large majority of this code is just C that the C++ accepts with its more strict typing. Each commit in this PR targets migrating a single file at a time.

My intention is to let the CI think about this and shake out where we might need some compiler specific stuff to make sure that C++11 is really available to us.

With that proven, there are a couple of conceptually light refactorings that I'd like to make to clean up ownership semantics of the roots and the structures that they track so that we can use typed containers in our follow on work.

Hi,

I'm facing this error when I run 'npm start' on react-native folder.

[Error: Watcher took too long to load Try running watchman from your terminal https://facebook.github.io/watchman/docs/troubleshooting.html] Error: Watcher took too long to load Try running watchman from your terminal https://facebook.github.io/watchman/docs/troubleshooting.html at null._onTimeout (/Users/niccolo/Desktop/iOS Projects/react-native/packager/react-packager/src/FileWatcher/index.js:71:16) at Timer.listOnTimeout (timers.js:110:15)

ERROR: could not create packager - please shut down any existing instances that are already running.

I've just installed watchman via homebrew. How can I fix this error?

When I try to run watchamn watch some_dir_name I get this error:

/Users/piotrpalek/Library/LaunchAgents/com.github.facebook.watchman.plist: Operation not permitted
1417520511: tid=2122277632 unable to talk to your watchman!

I am using OSX Yosemite and installed watchman via homebrew.

Command watchman -v (and any other commands) fails after binaries installation (Linux installation guide) with error:

watchman: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory

I fixed this error with the solution of smmoosavi here but another error appears:

terminate called after throwing an instance of 'std::system_error'
terminate called recursively
Aborted (core dumped)

Any ideas how to fix it? I tried different version of binaries but the result is the same...

When we first started out the thought was that very few directories would be ignored, but as we have progressed various internal projects have added a surprising number of ignore dirs in our internal repos.

We now find that our simplistic ignore checker is underperforming, particularly in the ignore-miss case as we have to compare N string prefixes before realizing that there is no match.

This pull request is a short series of diffs that:

1. Imports an Adaptive Radix Tree implementation that we will use as accelerator for string prefix matching
2. Adds unit tests for the underlying ignore checking functions that are used only on OS X and Windows
3. Augments the Radix Tree implementation with a function that can find the longest matching prefix
4. Benchmarks the prefix matching tree implementation against the prior simplistic solution
5. Replaces the old solution with the prefix matching tree implementation.

The benchmarks show that, for an ignore_dirs list of equivalent size and content as one used in a real repo, that the ignore-miss case is now approximately 11x faster and the ignore-hit case is approximately 2x faster. The latter can also be up to 11x faster if the ignore rule that is hit is towards the end of the ignore list.

The latency of this routine is important to minimize the risk of an overflow event.

The first thing is that it says on the site that I can pass in a string, but watchman will complain that it's not an array:

watchman -j <<-EOT
> ["query", "/Users/amasad/fbobjc-hg", { "path": "hi" }]
> EOT
{
    "version": "3.2.0",
    "error": "failed to parse query: 'path' must be an array"
}

Second, when I pass in array of strings:

1. It's ignored
2. Takes very long to finish the operation

I'm working around this by having an anyof expression with dirnames.

Issue

Requesting the symlink_target field causes Watchman to fail to respond to queries, or send unilateral subscription notifications, where the response would include a deleted symlink. A subscription enters a zombie state and never sends any further notifications. A query hangs the client.

This can be reproduced by deleting a symlink and performing a "since" query with a pre-deletion clock.

(Reporting this on GitHub to provide an OSS reference point for Metro etc)

Environment

Version: 20221208

Working: ✅ Eden on macOS (reports symlink_target: null after deletion)

Not working: ❌ kqueue+fsevents on macOS ❌ fsevents on macOS ❌ inotify on Linux ❌ win32 on Windows (Watchman 20220918.223204.0 from Choco)

watchman-diag (macOS): P587187472

Reproduction script

(requires jq to parse a clock out of the initial query)

#! /bin/sh

WATCH_ROOT="$TMPDIR/watchman-symlink-deletion"

rm -r "$WATCH_ROOT"
mkdir "$WATCH_ROOT"

REQUEST_FIELDS='["name", "exists"]'
if [ "$SYMLINKS" == "1" ]
then
    REQUEST_FIELDS='["name", "exists", "symlink_target"]'
fi

echo "Working in $WATCH_ROOT"
echo '{}' > "$WATCH_ROOT/.watchmanconfig"
ln -s  "any-target" "$WATCH_ROOT/my-link"

watchman watch-project "$WATCH_ROOT"

INITIAL_RESULT=$(watchman -j --server-encoding=json <<-EOF
["query", "$WATCH_ROOT", {
  "fields": ["name", "exists"]
}]
EOF
)
CLOCK=$(echo "$INITIAL_RESULT" | jq '.clock');

echo "Symlink exists at: $CLOCK"

echo "Deleting symlink"
rm "$WATCH_ROOT/my-link"

echo "Performing since query (fields=$REQUEST_FIELDS)"
watchman -j --server-encoding=json <<-EOF
["query", "$WATCH_ROOT", {
  "since": $CLOCK,
  "fields": $REQUEST_FIELDS
}]
EOF

echo "Success";

Output

SYMLINKS=1 ./watchman-query-test.sh (broken)

Working in /var/folders/f6/jkxrp7ms5f92b62wkbn369qw0000gn/T//watchman-symlink-deletion
{
    "version": "20221208",
    "watcher": "kqueue+fsevents",
    "watch": "/private/var/folders/f6/jkxrp7ms5f92b62wkbn369qw0000gn/T/watchman-symlink-deletion"
}
Symlink exists at: "c:1671045928:15784:280:3"
Deleting symlink
Performing since query (fields=["name", "exists", "symlink_target"])

Process hangs

SYMLINKS=0 ./watchman-query-test.sh (working)

SYMLINKS=0 /bin/sh ./watchman-query-test.sh
Working in /var/folders/f6/jkxrp7ms5f92b62wkbn369qw0000gn/T//watchman-symlink-deletion
{
    "version": "20221208",
    "watcher": "kqueue+fsevents",
    "watch": "/private/var/folders/f6/jkxrp7ms5f92b62wkbn369qw0000gn/T/watchman-symlink-deletion"
}
Symlink exists at: "c:1671045928:15784:281:3"
Deleting symlink
Performing since query (fields=["name", "exists"])
{
    "version": "20221208",
    "files": [
        {
            "name": "my-link",
            "exists": false
        }
    ],
    "is_fresh_instance": false,
    "clock": "c:1671045928:15784:281:6",
    "debug": {
        "cookie_files": [
            "/private/var/folders/f6/jkxrp7ms5f92b62wkbn369qw0000gn/T/watchman-symlink-deletion/.watchman-cookie-robhogan-mbp-15784-1"
        ]
    }
}
Success

Log output

2022-12-28T11:37:44,992: [client=18473:stm=105553687604224:pid=79233] path /private/var/folders/f6/jkxrp7ms5f92b62wkbn369qw0000gn/T/watchman-symlink-deletion is on filesystem type apfs
2022-12-28T11:37:45,007: [client=18473:stm=105553687604224:pid=79233] failed to use watcher eden: apfs is not a FUSE file system.
2022-12-28T11:37:45,007: [client=18473:stm=105553687604224:pid=79233] root /private/var/folders/f6/jkxrp7ms5f92b62wkbn369qw0000gn/T/watchman-symlink-deletion using watcher mechanism kqueue+fsevents (auto was requested)
2022-12-28T11:37:45,008: [io 140281709287592 /private/var/folders/f6/jkxrp7ms5f92b62wkbn369qw0000gn/T/watchman-symlink-deletion] failed to open /private/var/folders/f6/jkxrp7ms5f92b62wkbn369qw0000gn/T/watchman-symlink-deletion/my-link, O_EVTONLY: No such file or directory
2022-12-28T11:37:45,008: [io 140281709287592 /private/var/folders/f6/jkxrp7ms5f92b62wkbn369qw0000gn/T/watchman-symlink-deletion] PERF: {"user_time": 0.00014999999999999999, "start_time": 1672227465.0081799, "elapsed_time": 0.00031500000000000001, "version": "20221208", "system_time": 0.00038900000000000002, "meta": {"root": {"recrawl_count": 0, "case_sensitive": false, "watcher": "kqueue+fsevents", "path": "/private/var/folders/f6/jkxrp7ms5f92b62wkbn369qw0000gn/T/watchman-symlink-deletion"}}, "pid": 15784, "description": "full-crawl"}
2022-12-28T11:37:45,008: [io 140281709287592 /private/var/folders/f6/jkxrp7ms5f92b62wkbn369qw0000gn/T/watchman-symlink-deletion] crawl complete

This output is generated during the initial query. There is no log output generated during the "since" query.

Bumps nokogiri from 1.13.9 to 1.13.10.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

pywatchman hasn't seen a release in 5 years: https://pypi.org/project/pywatchman/1.4.1/

The main watchman project is now incompatible with pywatchman meaning the pywatchman library is effectively dead without a new release.

I spent some time figuring out how to build it and have published an unofficial version from the latest (as of 2022-11-21) checkout. I've included some sparse notes within setup.py on how I built and published in case it's useful to anyone wanting to publish or maintain their own version, or to spur some interest from Meta folk that might want to publish an official update.

I don't expect this PR to be merged, particularly since only the first commit (fixing the build dir path) is relevant to the official distribution.

https://github.com/facebook/watchman/issues/1065 https://pypi.org/project/pywatchman-unofficial/1.5.0/

Update: https://github.com/facebook/watchman/issues/1073#issuecomment-1321058283

Hello, I am attempting to update the Nix package for Watchman, which is version 4.9: https://search.nixos.org/packages?channel=unstable&show=watchman&from=0&size=50&sort=relevance&type=packages&query=watchman

The build appears to fail here:

Traceback (most recent call last):
  File "/build/source/build/fbcode_builder/getdeps.py", line 1275, in <module>
    sys.exit(main())
  File "/build/source/build/fbcode_builder/getdeps.py", line 1258, in main
    return args.func(args)
  File "/build/source/build/fbcode_builder/getdeps.py", line 109, in run
    self.run_project_cmd(args, loader, manifest)
  File "/build/source/build/fbcode_builder/getdeps.py", line 575, in run_project_cmd
    cached_project = CachedProject(cache, loader, m)
  File "/build/source/build/fbcode_builder/getdeps.py", line 227, in __init__
    self.cache_file_name = "-".join(
TypeError: sequence item 1: expected str instance, NoneType found

which is:

https://github.com/facebook/watchman/blob/3e3b21c09d74f90b7342c26bbfa420c4e6b2da41/build/fbcode_builder/getdeps.py#L215-L236

The precise location of the error may be

https://github.com/facebook/watchman/blob/3e3b21c09d74f90b7342c26bbfa420c4e6b2da41/build/fbcode_builder/getdeps.py#L230

Can/should this be changed to

self.ctx.get("os") or "none",

?

This error can be replicated by checking out https://github.com/peterbecich/nixpkgs/tree/update-watchman , then cd to pkgs/development/tools/watchman, and nix-build

Thank you

Hi, I'm trying to install from source. Following instructions from here: https://facebook.github.io/watchman/docs/install.html#-building-from-source Steps I've taken are:

git clone https://github.com/facebook/watchman.git
cd watchman
git checkout -b v2022.11.07.00
sudo ./install-system-packages.sh
sudo ./autogen.sh

and this error appears

CMake Error at build/fbcode_builder/CMake/RustStaticLibrary.cmake:61 (find_program):
  Could not find CARGO_COMMAND using the following names: cargo
Call Stack (most recent call first):
  CMakeLists.txt:139 (include)

I do have cargo installed- in terminal running command cargo version returns cargo 1.65.0 (4bc8f24d3 2022-10-20)

I've also tried using the deb but get this error

dpkg: dependency problems prevent configuration of watchman:
 watchman depends on libevent-2.1-7; however:
  Package libevent-2.1-7 is not installed.

dpkg: error processing package watchman (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 watchman

I've attempted to install the above package but get a conflicting package error and I do not know how to resolve this.

sudo dpkg -i libevent-2.1-7_2.1.11-stable-1_amd64.deb 
dpkg: regarding libevent-2.1-7_2.1.11-stable-1_amd64.deb containing libevent-2.1-7:amd64:
 libevent-2.1-7a:amd64 conflicts with libevent-2.1-7
  libevent-2.1-7:amd64 (version 2.1.11-stable-1) is to be installed.

dpkg: error processing archive libevent-2.1-7_2.1.11-stable-1_amd64.deb (--install):
 conflicting packages - not installing libevent-2.1-7:amd64
Errors were encountered while processing:
 libevent-2.1-7_2.1.11-stable-1_amd64.deb

Thanks for your time. This is my first time raising an issue