Skip to content
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

Issue with RMD and full path on vsftpd #6504

Closed
cyberduck opened this issue Jan 25, 2012 · 8 comments
Closed

Issue with RMD and full path on vsftpd #6504

cyberduck opened this issue Jan 25, 2012 · 8 comments
Labels
bug ftp FTP Protocol Implementation high priority thirdparty Issue caused by third party

Comments

@cyberduck
Copy link
Collaborator

Anhubert created the issue

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?

@cyberduck
Copy link
Collaborator Author

@dkocher commented

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

@cyberduck
Copy link
Collaborator Author

Anhubert commented

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.

@cyberduck
Copy link
Collaborator Author

Anhubert commented

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. \

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:5 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.

@cyberduck
Copy link
Collaborator Author

Anhubert commented

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")                    Err11939 EINVAL

The "Err11939 EINVAL" seems to be an error if you rmdir a busy directory

@cyberduck
Copy link
Collaborator Author

Anhubert commented

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.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

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.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Duplicate for #5865.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug ftp FTP Protocol Implementation high priority thirdparty Issue caused by third party
Projects
None yet
Development

No branches or pull requests

1 participant