Cyberduck Mountain Duck CLI

Opened on Jan 25, 2012 at 11:30:19 AM

Closed on Jan 29, 2012 at 6:07:00 PM

Last modified on Mar 27, 2012 at 12:16:56 PM

#6504 closed defect (thirdparty)

Issue with RMD and full path on vsftpd

Reported by: Anhubert Owned by:
Priority: high Milestone:
Component: ftp Version: 4.2.1
Severity: blocker Keywords:
Cc: Architecture: Intel
Platform: Mac OS X 10.7

Description (last modified by dkocher)

Hi all,

I have following issue:

I login with FTPs, create a directory 

MKD /somedir/ahutest

and then i delete it 

RMD /somedir/ahutest
  • works

now again, I create the directory 

MKD /somedir/ahutest

then I log out and log in again and try to delete that: 

RMD /somedir/ahutest

And I get 

550 Remove directory operation failed.

now again, I create a directory 

MKD /somedir/ahutest

change to that directory 

CWD /somedir/ahutest

and create a subdirectory 

MKD /somedir/ahutest/ahusubtest

Now I want to delete that dir immediate 

RMD /somedir/ahutest/ahusubtest

And again 

550 Remove directory operation failed.

It looks like Cyberduck is always using the complete path when doing commands as seen above. If I use Filezilla, it does 

CWD somedir
CWD ahutest
RMD ahusubtest

and that works

So who has the bug, who has the problem and how to solve it? Is there a way to tell Cyberduck not to use the complete path in every command?

Change History (10)

comment:1 Changed on Jan 25, 2012 at 11:35:31 AM by Anhubert

  • Description modified (diff)

comment:2 Changed on Jan 25, 2012 at 11:41:57 AM by dkocher

  • Description modified (diff)

comment:3 Changed on Jan 25, 2012 at 11:46:21 AM by dkocher

We expect the server to handle absolute paths correctly. Do you know if you are using the latest version of vsftpd available?

comment:4 Changed on Jan 25, 2012 at 3:04:46 PM by Anhubert

latest is 2.3.5, I am using 2.3.0, because it is on Solaris and there is a precompiled package only for 2.3.0 available.

comment:5 follow-up: Changed on Jan 25, 2012 at 5:15:19 PM by Anhubert

maybe the problem is, that he is changing into the directory and trying to RMD it while he is still in it:
CWD /somedir/test/test2
250 Directory successfully changed.
TYPE A
200 Switching to ASCII mode.
PASV
227 Entering Passive Mode (80,72,140,13,15,176).
LIST -a
150 Here comes the directory listing.
drwxrwsrwx 2 867 867 2 Jan 25 17:12 .
drwxrwsrwx 3 867 867 3 Jan 25 17:12 ..
226 Directory send OK.
RMD /somedir/test/test2
550 Remove directory operation failed.
RMD /somedir/test
550 Remove directory operation failed.

Last edited on Jan 25, 2012 at 5:16:00 PM by Anhubert (previous) (diff)

comment:6 in reply to: ↑ 5 Changed on Jan 25, 2012 at 5:27:15 PM by dkocher

Replying to Anhubert:

Good point, that is very possible. But the server has no reason to lock the directory and/or should handle this as it is a file system specific implementation detail. Can you report a bug against vsftpd as well, please. We only had a similar issue with Windows file servers before.

comment:7 Changed on Jan 26, 2012 at 10:42:46 AM by Anhubert

I already opened a ticket at vsftpd: ​http://viki.brainsware.org/forum/thread/80

And I did a trace on the vsftp trace while trying to delete the directory and indeed: 

rmdir("/GenoPublisher/test")                    Err#22 EINVAL

The "Err#22 EINVAL" seems to be an error if you rmdir a busy directory

Last edited on Jan 29, 2012 at 6:07:37 PM by dkocher (previous) (diff)

comment:8 Changed on Jan 26, 2012 at 11:33:47 AM by Anhubert

I finally found out, that this is indeed a serious Bug!

I tried it with an older version 3.4.1, there the problem does not occure, here the details: 

CWD /somedir/test
250 Directory successfully changed. 
NOOP 
200 NOOP ok. 
STAT /somedir/test 
213-Status follows: 
drwxrwsrwx    2 867      867             2 Jan 26 01:30 . 
drwxrwsr-x    6 867      867            29 Jan 26 09:42 .. 
213 End of status 
PASV 
227 Entering Passive Mode (80,72,140,13,15,175). 
LIST -a 
150 Here comes the directory listing. 
drwxrwsrwx    2 867      867             2 Jan 26 01:30 . 
drwxrwsr-x    6 867      867            29 Jan 26 09:42 .. 
226 Directory send OK. 
CWD /somedir 
250 Directory successfully changed. 
RMD test 

And this is, how 4.3.1 acts: 
STAT /somedir/test/test2 
213-Status follows: 
drwxrwsrwx    2 867      867             2 Jan 26 11:28 . 
drwxrwsrwx    3 867      867             3 Jan 26 11:28 .. 
213 End of status 
CWD /somedir/test/test2 
250 Directory successfully changed. 
TYPE A 
200 Switching to ASCII mode. 
PASV 
227 Entering Passive Mode (80,72,140,13,15,167). 
LIST -a 
150 Here comes the directory listing. 
drwxrwsrwx    2 867      867             2 Jan 26 11:28 . 
drwxrwsrwx    3 867      867             3 Jan 26 11:28 .. 
226 Directory send OK. 
RMD /somedir/test/test2 
550 Remove directory operation failed. 
RMD /somedir/test 
550 Remove directory operation failed.

So the difference is 3.4.1 is changing one directory up, before trying to delete: 

CWD /somedir

Please fix that bug.

Last edited on Jan 29, 2012 at 6:04:46 PM by dkocher (previous) (diff)

comment:9 Changed on Jan 29, 2012 at 6:07:00 PM by dkocher

  • Component changed from core to ftp
  • Resolution set to thirdparty
  • Status changed from new to closed

Regardless of the current working directory the directory should be deletable according to the FTP protocol specification. This is a bug in vsftpd which is locking the directory.

comment:10 Changed on Mar 27, 2012 at 12:16:56 PM by dkocher

Duplicate for #5865.

Note: See TracTickets for help on using tickets.