-
-
Notifications
You must be signed in to change notification settings - Fork 618
nvim-tree
allows the creation of files over sshfs
, but they can't be accessed
#2794
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
Comments
Initial thoughts: this may be a file system notification issue. Does the folder show after you manually refresh I don't have any knowledge about ssh file systems however I imagine that libuv would have issues. It's definitely not something that nvim-tree is aware of or can handle. Suggestion: raise an issue with nosduco/remote-sshfs.nvim and see what ideas they have then we can talk further. I notice they copied our log subsystem :) |
Thanks, @alex-courtis. Unfortunately, no, I can only create files directly from |
Upon further digging, this is definitely a The issue arises solely with the vim.g.loaded_netrw = 1
vim.g.loaded_netrwPlugin = 1
vim.cmd [[set runtimepath=$VIMRUNTIME]]
vim.cmd [[set packpath=/tmp/nvt-min/site]]
local package_root = "/tmp/nvt-min/site/pack"
local install_path = package_root .. "/packer/start/packer.nvim"
local function load_plugins()
require("packer").startup {
{
"wbthomason/packer.nvim",
"nvim-tree/nvim-tree.lua",
"nvim-tree/nvim-web-devicons",
},
config = {
package_root = package_root,
compile_path = install_path .. "/plugin/packer_compiled.lua",
display = { non_interactive = true },
},
}
end
if vim.fn.isdirectory(install_path) == 0 then
print "Installing nvim-tree and dependencies."
vim.fn.system { "git", "clone", "--depth=1", "https://github.com/wbthomason/packer.nvim", install_path }
end
load_plugins()
require("packer").sync()
vim.cmd [[autocmd User PackerComplete ++once echo "Ready!" | lua setup()]]
vim.opt.termguicolors = true
vim.opt.cursorline = true
-- MODIFY NVIM-TREE SETTINGS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
_G.setup = function()
require("nvim-tree").setup {}
end
-- UNCOMMENT this block for diagnostics issues, substituting pattern and cmd as appropriate.
-- Requires diagnostics.enable = true in setup.
--[[
vim.api.nvim_create_autocmd("FileType", {
pattern = "lua",
callback = function()
vim.lsp.start { cmd = { "lua-language-server" } }
end,
})
]] |
Hi, facing the same issue. I have successfully used this plugin for fuse mounted file system using sshfs before, so it broke in some recent commit. |
Thank you, I can reproduce this with sshfs and default nvim-tree config. The directories are seen by nvim-tree, but not enumerated. Top level contains only directories: in this case baz and foo are seen, 2 is not.
Add a file 0 next to foo, no change. |
git bisect shows this to be the first bad commit |
It appears to be the fs_scandir_next that is failing. fs_stat seems reliable: ---@param handle uv.uv_fs_t
---@param cwd string
---@param node Node
---@param git_status table
local function populate_children(handle, cwd, node, git_status)
local node_ignored = explorer_node.is_git_ignored(node)
local nodes_by_path = utils.bool_record(node.nodes, "absolute_path")
local filter_status = filters.prepare(git_status)
while true do
local name, t, err = vim.loop.fs_scandir_next(handle)
log.line("dev", "child next %s %s %s", name, t, err)
if not name then
break
end
local abs = utils.path_join { cwd, name }
local res, ok, errr = vim.loop.fs_stat(abs)
log.line("dev", "child stat %s %s %s", res, ok, errr)
|
Will look into it, but I don't really have any experience with this. |
Thanks mate! Dev and contribution docs. |
Out of curiousity, I checked out a previous commit, and found that this bug is actually a regression. I will run a Edit: according to |
Should be fixed in #2893. Waiting review and merge. |
* add type fallback for nil types * add PR suggestions * Update lua/nvim-tree/explorer/explore.lua Co-authored-by: Alexander Courtis <[email protected]> * use type from fs_stat for sshfs compatibility --------- Co-authored-by: Alexander Courtis <[email protected]>
Thank you so much for fixing this. Now however, nvim-tree is extremely slow when using it on an sshfs mount, possibly because it is scanning the file system every time you open nvim tree. Is there a way to optimize this? Perhaps you could assume that when working on a mount, the current machine is the only one working on the file system and hence there is no need to update it every time? |
@Thiggel I believe the slowness you are experiencing is network latency and not nvim-tree. Could you test the mount using a file explorer or |
@mxple I have had a similar "lag" only when using |
@Thiggel Unfortunately there's not much we can do here - nvim-tree has to look at each file.
You might like to experiment with filesystem watchers: disabling or enabling (default)
You can be targeted about it, disabling them for specific directories:
|
This reverts commit 8405ecf. Fix for symlinks is simple
Hi @alex-courtis . Luckily, it seems there is a pretty simple fix where we replace I believe I have fixed both issues in (#2922). Please test and review. |
Apologies, yes, that was a bad refactor/rebase. |
* Revert "revert(#2794): sshfs compatibility (#2920)" This reverts commit 8405ecf. Fix for symlinks is simple * fix sshfs compatibility with symlinks * add suggestions * revert variable name change to ease multi-instance feature branch conflicts --------- Co-authored-by: Alexander Courtis <[email protected]>
Description
I'm using
nosduco/remote-sshfs.nvim
to work remotely over sshfs.nvim-tree
doesn't show anything from the mounted folder on the server, however, you can perform edit operations fromnvim-tree
directly, such as creating a new file (see image, I basically presseda
on top of the folder in nvim-tree panel).I checked on server and the file was indeed created.
Thanks
Neovim version
Operating system and version
macOS Sonoma 14.5 (23F79)
Windows variant
No response
nvim-tree version
{ "branch": "master", "commit": "517e4fbb9ef3c0986da7047f44b4b91a2400f93c" }
Clean room replication
Steps to reproduce
Expected behavior
List all files, directories, normal navigation as one would have locally.
Actual behavior
The text was updated successfully, but these errors were encountered: