savannah: Moving/copying single files to FTP VFS

[zlatk0]

Original: ​http://savannah.gnu.org/bugs/?13101

Submitted by:	Thomas Zajic <ZlatkO>	Submitted on:	Mon 16 May 2005 05:14:00 PM UTC
Category:	VFS	Severity:	2 - Minor
Status:	Postponed	Privacy:	Public
Assigned to:	Pavel Tsekov <ptsekov>	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 <ptsekov> 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 <ptsekov> 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 <ptsekov> 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 <ZlatkO> 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 <ptsekov> 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 <ZlatkO> 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 <ZlatkO> 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 <ptsekov> 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 <ptsekov> 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 <ptsekov> 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 <ZlatkO> 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 <ptsekov> 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 <ptsekov> 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 <ptsekov> 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.