-
Notifications
You must be signed in to change notification settings - Fork 995
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"error": "sync: creat(xxx) failed: Not a directory: not a directory" #501
Comments
Hmm, sounds fishy. We don't have git specific logic, but we do have this bit of logic: Lines 52 to 55 in a1bd090
The idea is that we want to place our sync cookies in a directory that doesn't participate in the SCM status operation in case we get killed and leave behind a junk file in the repo. We do this based on the vcs_ignore_dirs setting; this is just a list of dirs that we partially ignore (we watch only its direct contents, but not anything lower). We should only pick one of those dirs if it shows up as a dir, and that should make that "not a directory" error impossible. However, we do have this long standing issue that surfaced from an earlier attempt at integrating watchman with git: #25 Is it possible that that path in the error message was originally a nested git repo and that it was later swapped out for a subrepo? |
I looked into the test that was failing and yes, it does start out with a .git folder and then replaces it in a later test with a .git file. I read your proposed fix and it seems like it would solve the problem. |
Summary: I got here because `btrfs` doesn't send `IN_DELETE_SELF` notifications when a watched subvolume is unmounted. Until that is addresses in the kernel we tackle this from a different angle. We periodically perform a synchronized `clock` call against each of the watches. When that happens and a btrfs volume has been deleted then the cookie sync will error out because the directory structure no longer exists. Let's catch that case and generate a recrawl; the recrawl will discover the removal and cancel the watch. And while we're in here, let's also deal with just the vcs subdir going away. Refs: #25 Refs: #501 Reviewed By: simpkins Differential Revision: D7014364 fbshipit-source-id: 9acd20efa843563626b73c6f6e34c3787dd28a39
Summary: I got here because `btrfs` doesn't send `IN_DELETE_SELF` notifications when a watched subvolume is unmounted. Until that is addresses in the kernel we tackle this from a different angle. We periodically perform a synchronized `clock` call against each of the watches. When that happens and a btrfs volume has been deleted then the cookie sync will error out because the directory structure no longer exists. Let's catch that case and generate a recrawl; the recrawl will discover the removal and cancel the watch. And while we're in here, let's also deal with just the vcs subdir going away. Refs: facebook#25 Refs: facebook#501 Reviewed By: simpkins Differential Revision: D7014364 fbshipit-source-id: 9acd20efa843563626b73c6f6e34c3787dd28a39
Summary: I got here because `btrfs` doesn't send `IN_DELETE_SELF` notifications when a watched subvolume is unmounted. Until that is addresses in the kernel we tackle this from a different angle. We periodically perform a synchronized `clock` call against each of the watches. When that happens and a btrfs volume has been deleted then the cookie sync will error out because the directory structure no longer exists. Let's catch that case and generate a recrawl; the recrawl will discover the removal and cancel the watch. And while we're in here, let's also deal with just the vcs subdir going away. Refs: facebook#25 Refs: facebook#501 Reviewed By: simpkins Differential Revision: D7014364 fbshipit-source-id: 9acd20efa843563626b73c6f6e34c3787dd28a39
When testing watchman with git submodules, I execute the following query:
["query", "C:/git-sdk-64/usr/src/git/t/trash directory.t7506-status-submodule/sub", {"since": 1499713020, "fields": ["name"], "expression": ["not", ["allof", ["since", 1499713020, "cclock"], ["not", "exists"]]]}]
Which results in the following error:
{
"version": "4.9.0",
"error": "sync: creat(C:/git-sdk-64/usr/src/git/t/trash directory.t7506-status-submodule/sub/.git/.watchman-cookie-BenPeart-HP-58768-13) failed: Not a directory: not a directory"
}
$ watchman version
{
"version": "4.9.0",
"buildinfo": "981452aff98ee5064c06a3a8cd39ff2394846114 2017-07-03T21:52:36.0000000Z"
}
It appears that there is some git specific code in Watchman (note the path contains "/sub/.git/.watchman" which in the case of sub modules, is invalid. Sub-modules take advantage of the git feature that allows the .git folder to be replaced with a .git file that contains the path to the actual folder. Here is the contents of the sub/.git file:
$ cat .git
gitdir: C:/git-sdk-64/usr/src/git/t/trash directory.t7506-status-submodule/sub/../.real
I'm surprised/worried that Watchman has git specific logic but if it needs to continue to exist, Watchman will need to handle the case where .git is a file instead of a folder as this can happen in any .git repo in addition to being used for sub-modules.
I also wonder if this (creating a cookie) is contributing to the random errors where a file is in use within a folder which prevents the folder from being deleted. I'll report that separately.
The text was updated successfully, but these errors were encountered: