From: Darin M. <dar...@sh...> - 2011-07-07 03:36:23
|
After trying 2.3, I'm finding that one mount point that I regularly make is giving: $ ls /ihome ls: cannot access /ihome: Input/output error whereas another mountpoint on the same server works fine. Both mount points work just fine with 2.2, simultaneously. Mount command: ./sshfs -o transform_symlinks -o allow_root root@server:/ihome /ihome The other mount point is exactly the same, except /ihome changes to another directory. Note that on the server, /ihome is a symlink to /home. Whereas this worked with 2.2, this seems a regression with 2.3 (or is that a bugfix that shouldn't have worked in 2.2?). I'm not sure this is the problem, but it seems suspicious. Thanks, |
From: Darin M. <dar...@sh...> - 2011-07-15 18:19:22
|
On July 6, 2011 9:36:14 PM Darin McBride wrote: > After trying 2.3, I'm finding that one mount point that I regularly make is > giving: > > $ ls /ihome > ls: cannot access /ihome: Input/output error > > whereas another mountpoint on the same server works fine. Both mount > points work just fine with 2.2, simultaneously. > > Mount command: > > ./sshfs -o transform_symlinks -o allow_root root@server:/ihome /ihome > > The other mount point is exactly the same, except /ihome changes to another > directory. > > Note that on the server, /ihome is a symlink to /home. Whereas this worked > with 2.2, this seems a regression with 2.3 (or is that a bugfix that > shouldn't have worked in 2.2?). I'm not sure this is the problem, but it > seems suspicious. Can anyone else reproduce? Is there a better place to report bugs than here? I can't find anywhere on sourceforge to track bugs for this project. |
From: Miklos S. <mi...@sz...> - 2011-07-19 11:59:48
|
Darin McBride <dar...@sh...> writes: > On July 6, 2011 9:36:14 PM Darin McBride wrote: >> After trying 2.3, I'm finding that one mount point that I regularly make is >> giving: >> >> $ ls /ihome >> ls: cannot access /ihome: Input/output error >> >> whereas another mountpoint on the same server works fine. Both mount >> points work just fine with 2.2, simultaneously. >> >> Mount command: >> >> ./sshfs -o transform_symlinks -o allow_root root@server:/ihome /ihome >> >> The other mount point is exactly the same, except /ihome changes to another >> directory. >> >> Note that on the server, /ihome is a symlink to /home. Whereas this worked >> with 2.2, this seems a regression with 2.3 (or is that a bugfix that >> shouldn't have worked in 2.2?). I'm not sure this is the problem, but it >> seems suspicious. > > Can anyone else reproduce? Is there a better place to report bugs > than here? I can't find anywhere on sourceforge to track bugs for > this project. Thanks for the bug report. I can reproduce this. The solution is to add an ending slash to the remote path: ./sshfs -o transform_symlinks -o allow_root root@server:/ihome/ /ihome The following patch fixes the I/O error, instead it will fail at mount time, which I think is the correct behavior. Thanks, Miklos --- diff --git a/sshfs.c b/sshfs.c index 22bda6b..d26e2c1 100644 --- a/sshfs.c +++ b/sshfs.c @@ -1525,7 +1525,7 @@ static int sftp_check_root(const char *base_path) buf_init(&buf, 0); buf_add_string(&buf, remote_dir); buf_to_iov(&buf, &iov[0]); - if (sftp_send_iov(SSH_FXP_STAT, id, iov, 1) == -1) + if (sftp_send_iov(SSH_FXP_LSTAT, id, iov, 1) == -1) goto out; buf_clear(&buf); if (sftp_read(&type, &buf) == -1) |
From: Darin M. <dar...@sh...> - 2011-07-21 16:34:39
|
On July 19, 2011 6:00:36 AM Miklos Szeredi wrote: > Darin McBride <dar...@sh...> writes: > > On July 6, 2011 9:36:14 PM Darin McBride wrote: > >> After trying 2.3, I'm finding that one mount point that I regularly make > >> is giving: > >> > >> $ ls /ihome > >> ls: cannot access /ihome: Input/output error > >> > >> whereas another mountpoint on the same server works fine. Both mount > >> points work just fine with 2.2, simultaneously. > >> > >> Mount command: > >> > >> ./sshfs -o transform_symlinks -o allow_root root@server:/ihome /ihome > >> > >> The other mount point is exactly the same, except /ihome changes to > >> another directory. > >> > >> Note that on the server, /ihome is a symlink to /home. Whereas this > >> worked with 2.2, this seems a regression with 2.3 (or is that a bugfix > >> that shouldn't have worked in 2.2?). I'm not sure this is the problem, > >> but it seems suspicious. > > > > Can anyone else reproduce? Is there a better place to report bugs > > than here? I can't find anywhere on sourceforge to track bugs for > > this project. > > Thanks for the bug report. I can reproduce this. > > The solution is to add an ending slash to the remote path: > > ./sshfs -o transform_symlinks -o allow_root root@server:/ihome/ /ihome > > The following patch fixes the I/O error, instead it will fail at mount > time, which I think is the correct behavior. So, the behaviour that we have in 2.2 is incorrect? Also, my distro's bug report, https://bugs.gentoo.org/show_bug.cgi?id=375305 , gives the response that -o follow_symlinks would work. But I still come back to the fact that it worked in 2.2 and this seems like a regression. Thanks, |
From: Miklos S. <mi...@sz...> - 2011-07-22 15:33:33
|
Darin McBride <dar...@sh...> writes: > On July 19, 2011 6:00:36 AM Miklos Szeredi wrote: >> Darin McBride <dar...@sh...> writes: >> > On July 6, 2011 9:36:14 PM Darin McBride wrote: >> >> After trying 2.3, I'm finding that one mount point that I regularly make >> >> is giving: >> >> >> >> $ ls /ihome >> >> ls: cannot access /ihome: Input/output error >> >> >> >> whereas another mountpoint on the same server works fine. Both mount >> >> points work just fine with 2.2, simultaneously. >> >> >> >> Mount command: >> >> >> >> ./sshfs -o transform_symlinks -o allow_root root@server:/ihome /ihome >> >> >> >> The other mount point is exactly the same, except /ihome changes to >> >> another directory. >> >> >> >> Note that on the server, /ihome is a symlink to /home. Whereas this >> >> worked with 2.2, this seems a regression with 2.3 (or is that a bugfix >> >> that shouldn't have worked in 2.2?). I'm not sure this is the problem, >> >> but it seems suspicious. >> > >> > Can anyone else reproduce? Is there a better place to report bugs >> > than here? I can't find anywhere on sourceforge to track bugs for >> > this project. >> >> Thanks for the bug report. I can reproduce this. >> >> The solution is to add an ending slash to the remote path: >> >> ./sshfs -o transform_symlinks -o allow_root root@server:/ihome/ /ihome >> >> The following patch fixes the I/O error, instead it will fail at mount >> time, which I think is the correct behavior. > > So, the behaviour that we have in 2.2 is incorrect? Yes, although not blatantly incorrect. > Also, my distro's bug report, > https://bugs.gentoo.org/show_bug.cgi?id=375305 , gives the response > that -o follow_symlinks would work. But I still come back to the fact > that it worked in 2.2 and this seems like a regression. Yes, you are correct that this is a regression. The following patch should get back the old behavior. Thanks, Miklos diff --git a/sshfs.c b/sshfs.c index 22bda6b..23ad13f 100644 --- a/sshfs.c +++ b/sshfs.c @@ -195,6 +195,7 @@ struct sshfs { int delay_connect; char *host; char *base_path; + char *base_path_orig; GHashTable *reqtab; pthread_mutex_t lock; pthread_mutex_t lock_write; @@ -1510,7 +1511,7 @@ out: buf_free(&buf); } -static int sftp_check_root(const char *base_path) +static int sftp_check_root(void) { int flags; uint32_t id = sftp_get_id(); @@ -1520,12 +1521,17 @@ static int sftp_check_root(const char *base_path) struct stat stbuf; struct iovec iov[1]; int err = -1; - const char *remote_dir = base_path[0] ? base_path : "."; + const char *remote; + int retried = 0; + remote = sshfs.base_path_orig[0] ? sshfs.base_path_orig : "."; + +retry: buf_init(&buf, 0); - buf_add_string(&buf, remote_dir); + buf_add_string(&buf, remote); buf_to_iov(&buf, &iov[0]); - if (sftp_send_iov(SSH_FXP_STAT, id, iov, 1) == -1) + if (sftp_send_iov(sshfs.follow_symlinks ? SSH_FXP_STAT : SSH_FXP_LSTAT, + id, iov, 1) == -1) goto out; buf_clear(&buf); if (sftp_read(&type, &buf) == -1) @@ -1545,7 +1551,7 @@ static int sftp_check_root(const char *base_path) if (buf_get_uint32(&buf, &serr) == -1) goto out; - fprintf(stderr, "%s:%s: %s\n", sshfs.host, remote_dir, + fprintf(stderr, "%s:%s: %s\n", sshfs.host, remote, strerror(sftp_error_to_errno(serr))); goto out; @@ -1556,14 +1562,20 @@ static int sftp_check_root(const char *base_path) if (!(flags & SSH_FILEXFER_ATTR_PERMISSIONS)) goto out; + if (S_ISLNK(stbuf.st_mode) && S_ISDIR(sshfs.mnt_mode) && !retried) { + remote = sshfs.base_path; + retried = 1; + buf_free(&buf); + goto retry; + } + if (S_ISDIR(sshfs.mnt_mode) && !S_ISDIR(stbuf.st_mode)) { - fprintf(stderr, "%s:%s: Not a directory\n", sshfs.host, - remote_dir); + fprintf(stderr, "%s:%s: Not a directory\n", sshfs.host, remote); goto out; } if ((sshfs.mnt_mode ^ stbuf.st_mode) & S_IFMT) { fprintf(stderr, "%s:%s: type of file differs from mountpoint\n", - sshfs.host, remote_dir); + sshfs.host, remote); goto out; } @@ -3220,7 +3232,7 @@ static int ssh_connect(void) return -1; if (!sshfs.no_check_root && - sftp_check_root(sshfs.base_path) == -1) + sftp_check_root() == -1) return -1; } @@ -3284,7 +3296,9 @@ int main(int argc, char *argv[]) } fsname = g_strdup(sshfs.host); - sshfs.base_path = g_strdup(find_base_path()); + sshfs.base_path_orig = g_strdup(find_base_path()); + sshfs.base_path = sshfs.base_path_orig; + if (sshfs.ssh_command) set_ssh_command(); @@ -3364,6 +3378,17 @@ int main(int argc, char *argv[]) } sshfs.mnt_mode = st.st_mode; + /* + * If this is a directory, ensure that base path ends + * in a slash. This ensures compatibility with + * earlier versions of sshfs. + */ + if (S_ISDIR(sshfs.mnt_mode) && sshfs.base_path[0] && + sshfs.base_path[strlen(sshfs.base_path)-1] != '/') { + sshfs.base_path = g_strdup_printf("%s/", + sshfs.base_path_orig); + } + ch = fuse_mount(mountpoint, &args); if (!ch) exit(1); |
From: Navneet K. <nav...@gm...> - 2012-10-05 19:45:07
|
Hi Miklos, For me this error does not go even after I insert the trailing slash. The problem occurs after I shut my computer down or make it go to sleep without unmounting the remote directory. When I try to mount it again, I get this error. Right now, as stupid as it may sound, the only 'solution' I have been able to use is to move this directory and then, create another with the same name. (I am unable to delete it too.) Any ideas? Thanks a lot! Navneet Kapur. |