-
Notifications
You must be signed in to change notification settings - Fork 42
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
Directory becomes temporarily inaccessible after it has been moved #92
Comments
Huh! Funny that you report this issue just today. I've spent all day troubleshooting another problem I encountered and found a pretty serious bug in |
The readdir implementation would generate new nodes for every directory it encountered, even if they had seen before, returning new inodes each time. Other than this having a performance impact, this is just incorrect and I'm not sure how this bug has survived for so long. In fact, the only reason I noticed this is because I tried to build GNU tar on top of sandboxfs and its configure script would fail when run as root. Essentially, the test was doing a rename of a directory inside a directory, and that somehow caused the pwd to become invalid when performing a readdir on the parent directory. Should fix bazelbuild#92.
Alright. The problem doesn't reproduce on macOS as you describe it because of, I believe, differences in OSXFUSE. But I could reproduce it on Linux; thanks for the report. This is, indeed, the same problem I found earlier today, which manifested in a different manner but also involved a rename along with reading the directory contents (what you triggered with tab completion). The problem was that because we don't cache directory nodes, I've just pushed a fix to Travis for testing and will merge when tests pass. |
The readdir implementation would generate new nodes for every directory it encountered, even if they had seen before, returning new inodes each time. Other than this having a performance impact, this is just incorrect and I'm not sure how this bug has survived for so long. In fact, the only reason I noticed this is because I tried to build GNU tar on top of sandboxfs and its configure script would fail when run as root. Essentially, the test was doing a rename of a directory inside a directory, and that somehow caused the pwd to become invalid when performing a readdir on the parent directory. The issue is easier to reproduce on Linux though. Fixes bazelbuild#92.
The readdir implementation would generate new nodes for every directory it encountered, even if they had seen before, returning new inodes each time. Other than this having a performance impact, this is just incorrect and I'm not sure how this bug has survived for so long. In fact, the only reason I noticed this is because I tried to build GNU tar on top of sandboxfs and its configure script would fail when run as root. Essentially, the test was doing a rename of a directory inside a directory, and that somehow caused the pwd to become invalid when performing a readdir on the parent directory. The issue is easier to reproduce on Linux though. Fixes #92.
Thanks for your extremely quick response to the issue! I built the latest top of tree (855834e) and it fixes the issue described in my initial posting. However, there seems to be a new issue with files located in directories that get moved. Below is an error case that I can reliably reproduce with my own build of 855834e: Terminal 1:
Terminal 2:
There's no need to use TAB auto-completion to trigger the issue. In addition, |
Would you mind filing a separate bug for this problem please? This issue is now closed and referenced in the commit/changelog already so it'd be confusing to talk about its number for a different problem. I think I know what's happening and it's not the same root cause. (During a directory rename, we update the inode cache for the directory itself... but not for any of its contents.) Wow, I'm surprised these obvious problems haven't shown up until now, as I've been (ab)using sandboxfs quite a bit with Bazel builds or with pkg_comp builds. But I think OSXFUSE and Linux's FUSE behave quite differently in these cases, and I have done very little testing on the latter. |
Sure thing. Filed #94. |
When moving directories inside a sandbox, it takes a few seconds for the directories to become accessible. Directories are listed, but
ls
cannotstat()
the directory entries.For reproducing the issue, Bash auto completion has to be used when typing the directory names. By copy-pasting the commands as is, the directory that gets moved is immediately accessible.
Terminal 1:
Terminal 2:
In the example above, it took roughly 45 seconds for the directory to become accessible.
This was run on Ubuntu 16.04 workstation with 4.4.0-133-generic kernel and ext4 root file system. Sandboxfs is pre-built release 0.1.1 from
sandboxfs-0.1.1-20191024-linux-x86_64.tgz
.The issue has been reproduced also on Ubuntu 18.04 workstation with 4.15.0-72-generic kernel.
The text was updated successfully, but these errors were encountered: