id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,blockedby,blocking,branch_state,votes 13,savannah: Moving/copying single files to FTP VFS,zlatk0,,"Original: http://savannah.gnu.org/bugs/?13101 ||Submitted by:||Thomas Zajic ||Submitted on:||Mon 16 May 2005 05:14:00 PM UTC|| ||Category:||VFS||Severity:||2 - Minor|| ||Status:||Postponed||Privacy:||Public|| ||Assigned to:||Pavel Tsekov ||Open/Closed:||Open|| ||Release:||current (CVS or snapshot)||Operating System:||All|| Original submission: {{{ Originally sent to mc-devel[1]: --- BEGIN ORIGINAL MESSAGE --- When moving/copying a single file to an FTP VFS where I only have execute permission on the parent directory (ie. no read and write), I have to add a trailing slash (""/"") to the target specification manually, or else I get a ""Permission denied"" from the FTP server. Copying/moving multiple files works fine. This might be some sort of special case, actually. Here's the file hierarchy and permission details: [root blah]:/home/ftp/blahftp# ls -la total 32 drwxrwx--x 4 root ftp 4096 Jan 13 15:56 . drwxr-xr-x 9 root root 4096 Oct 5 18:09 .. drwxrwxrwx 2 ftp ftp 20480 Jan 15 14:18 hidden_dir_1 drwxrwxrwx 2 ftp ftp 4096 Dec 19 16:50 hidden_dir_2 [...] [root blah]:/home/ftp/blahftp# The net effect of this is that you have full access to the hidden_dirs, but you have to know its name. If you log on to the FTP server's root, it appears empty, and you're not allowed to upload files or create directories there (yes, I'm aware that this is security by obscurity, thank you very much ;-). Coming back to the problem at hand, when I want to copy/move a single file to hidden_dir_2 (ie. the target specification in the copy/move dialog box is ""/#ftp:ftp.security-by-obscurity.net/hidden_dir_2""), I get ""Permission denied"". If I manually add a trailing slash (ie. target specification ""/#ftp:ftp.security-by-obscurity.net/hidden_dir_2/""), it works fine. Copying/moving multiple files also works fine even without a trailing slash, somehow mc seems to automagically do the right thing in this case. It's not a big problem, to be honest, but merely a minor annoyance. --- END ORIGINAL MESSAGE --- This bug is still present as of mc-4.6.1-pre4a. Just adding this to Savannah to make sure it's not forgotten. [1] http://mail.gnome.org/archives/mc-devel/2005-January/msg00020.html }}} Comment 1 by Pavel Tsekov at Fri 17 Feb 2006 01:18:56 PM UTC: {{{ MC maintains an internal representation of the remote end's directory structure and it is used by calls such as stat(). In the described setup MC is unable to determine that hidden_dir_[12] actually exist because listing the parent directory yields no entries. As a result it doesn't have entries for hidden_dir_[12] in its internal cache and subsequent calls to stat() with those directory names fail and MC cannot determine that they are directories. I'll try to find the best way to fix this. }}} Comment 2 by Pavel Tsekov at Tue 21 Feb 2006 03:10:14 PM UTC: {{{ Please, test the attached patch. It is a simple one-liner. I think this is the right way to solve the described issue, however I'll not commit without the agreement of other developers. Andrew, please, comment if possible. }}} Comment 3 by Pavel Tsekov at Tue 21 Feb 2006 03:11:19 PM UTC: {{{ I forgot to attach the patch, so here it comes. }}} Comment 4 by Thomas Zajic at Thu 23 Feb 2006 07:00:36 AM UTC: {{{ The patch doesn't seem to fix the problem for me, I'm afraid. Actually, also the workaround of adding a trailing ""/"" slash manually doesn't work anymore now. Instead of ""Permission denied"", I now get ""Cannot overwrite directory ""/#ftp:ftp.security-by-obscurity.net/hidden_dir_2/testfile"" - Success (0), [ Skip ] [ Retry ] [ Abort ]"" in both cases (ie. with and without adding a trailing ""/"" manually), for both copying and moving a single file (""testfile""). Moreover, copying/moving multiple files now also doesn't work anymore, both with and without adding a trailing ""/"" manually, showing the same error message. Just in case this matters, while mc displays the error dialog, the destination panel shows ""ftpfs: failed; nowhere to fallback to"" in the top line where it normally shows the directory name. I don't think that's significant, though, as it also shows the same without the patch applied, but still copies/moves the file(s) properly. BTW I applied your patch to the plain vanilla 4.6.1 tarball from ibiblio.org - should I be using a CVS version instead? }}} Comment 5 by Pavel Tsekov at Thu 23 Feb 2006 08:24:48 AM UTC: {{{ The patch is against MC from CVS - sorry, that I didn't mention it. Please, test with CVS version of MC. If this is not an option, please, let me know and I'll give MC 4.6.1 a try. }}} Comment 6 by Thomas Zajic at Fri 24 Feb 2006 06:31:35 AM UTC: {{{ Tested with today's CVS version (20060224), same problem. Here's the FTP server's log from that session, trying to copy/move testfile1, then testfile1 and testfile2 into hidden_dir. It looks like mc doesn't even try to transfer anything, all it does is send LIST commands: xxx.xxx.xxx UNKNOWN nobody [24/Feb/2006:06:59:08 +0100] ""USER test"" 331 - xxx.xxx.xxx UNKNOWN test [24/Feb/2006:06:59:08 +0100] ""PASS (hidden)"" 230 - xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:08 +0000] ""PWD"" 257 - xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:08 +0000] ""PASV"" 227 - xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:08 +0000] ""TYPE A"" 200 - xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:08 +0000] ""LIST -la /hidden_dir/."" 226 115 xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:11 +0000] ""PASV"" 227 - xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:11 +0000] ""LIST -la /."" 226 0 xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:11 +0000] ""PASV"" 227 - xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:11 +0000] ""LIST -la /hidden_dir/testfile1/."" 226 0 xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:13 +0000] ""PASV"" 227 - xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:13 +0000] ""LIST -la /hidden_dir/."" 226 115 xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:18 +0000] ""PASV"" 227 - xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:18 +0000] ""LIST -la /."" 226 0 xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:18 +0000] ""PASV"" 227 - xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:18 +0000] ""LIST -la /hidden_dir/testfile1/."" 226 0 xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:20 +0000] ""PASV"" 227 - xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:20 +0000] ""LIST -la /hidden_dir/."" 226 115 xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:31 +0000] ""PASV"" 227 - xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:31 +0000] ""LIST -la /."" 226 0 xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:31 +0000] ""PASV"" 227 - xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:31 +0000] ""LIST -la /hidden_dir/testfile1/."" 226 0 xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:32 +0000] ""PASV"" 227 - xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:32 +0000] ""LIST -la /hidden_dir/testfile2/."" 226 0 xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:35 +0000] ""PASV"" 227 - xxx.xxx.xxx UNKNOWN test [24/Feb/2006:05:59:35 +0000] ""LIST -la /hidden_dir/."" 226 115 xxx.xxx.xxx UNKNOWN test [24/Feb/2006:06:01:56 +0000] ""QUIT"" 221 - Using active (PORT) instead of passive (PASV) FTP doesn't make any difference, except that the log file shows ""PORT"" commands where it shows ""PASV"" above. }}} Comment 7 by Thomas Zajic at Fri 24 Feb 2006 06:47:08 AM UTC: {{{ UPDATE: I just found out that the patch does indeed fix the problem for both vanilla 4.6.1 and 4.6.1a-CVS, if I also change ""ftpfs_first_cd_then_ls"" from ""0"" to ""1"" in ~/.mc/ini. This is an acceptable solution for me, so as far as I'm concerned, feel free to commit the patch and mark this bug fixed. Thanks a lot! :-) }}} Comment 8 by Pavel Tsekov at Mon 06 Mar 2006 08:35:11 AM UTC: {{{ ftpfs_first_cd_then_ls set to 0 is unreliable. In fact ftpfs_first_cd_then_ls is set by default for some time now. Of course I should have mentioned that :( Anyway I'll see why the patch breaks the old behaviour when ftpfs_first_cd_then_ls is unset. }}} Comment 9 by Pavel Tsekov at Wed 08 Mar 2006 03:00:47 PM UTC: {{{ I've just checked in a patch which improves ftpfs_dir_load(). It enables the attached patch to work no matter whether `ftpfs_first_cd_then_ls' is set or not. So if you checkout the source from cvs it should work. }}} Comment 10 by Pavel Tsekov at Wed 08 Mar 2006 03:02:04 PM UTC: {{{ If it is not clear you still should apply the patch attached to this bugreport since I haven't commited that yet. }}} Comment 11 by Thomas Zajic at Thu 09 Mar 2006 12:15:01 AM UTC: {{{ Yes, both moving and copying a single file works fine now (latest CVS with the attached patch applied), even with ftpfs_first_cd_then_ls=0. Again, thanks a lot! :-) }}} Comment 12 by Pavel Tsekov at Thu 09 Mar 2006 08:48:55 AM UTC: {{{ I'll wait till 21 March before commiting this patch. That's almost two weeks - I think this is enough time for other developers to comment. }}} Comment 13 by Pavel Tsekov at Thu 23 Mar 2006 12:37:47 PM UTC: {{{ I've commited the patch. Closing the bugreport as fixed. }}} Comment 14 by Pavel Tsekov at Thu 30 Mar 2006 12:57:52 PM UTC: {{{ Reopening this one. I'll revert the patch since it breaks fish. Once I fix this breakage I'll commit it again. }}} ",defect,new,major,Future Releases,mc-vfs,4.6.1,,,,,,no branch,