bug: CWD in unftp_sbe_opendal is broken due '/' requirement in path end

[vdudouyt]

Describe the bug

After having #5380 fixed (@Frank-III thank you very much for that!), now I'm having troubles with CWDing in a newly created directory due to the same problem. I also have a strong impression that every command (except for MKD as it was fixed in #5380) involving directories is broken due to a convention that requires adding "/" to each directory path - including CWD, DELE, LIST, MLSD and others.

#[tokio::main]
async fn main() -> Result<()> {
    let builder = opendal::services::Memory::default()
        .root("/");
    let op = Operator::new(builder)?.finish();
    let backend = OpendalStorage::new(op);
    let server = libunftp::ServerBuilder::new(Box::new(move || backend.clone()))
        .greeting("Welcome to my FTP server")
        .active_passive_mode(ActivePassiveMode::PassiveOnly)
        .passive_ports(50000..65535)
        .build().unwrap();

    let _ = server.listen("0.0.0.0:21").await;
    Ok(())
}

In my Filezilla log I have:

Command:	CWD Test
Response:	550 Directory not found

In my env_logger I have:

[2024-12-05T17:46:10Z WARN  libunftp::server::controlchan::commands::cwd] CWD: Failed to change directory "/Test": storage error: 550 Permanent directory not available , source: 194.146.156.130:4394, trace-id: 0xdb87ac25ab1c8303

Is it possible to fix that and add some regression tests to prevent that from occurring again in the future?

Steps to Reproduce

1. Run any application using unftp_sbe_opendal and OpenDAL v0.52.0. You can use main.rs from example above
2. Connect with FTP client (personally, I'm using Filezilla)
3. Create a directory
4. Try to perform any operation with that directory (like entering in, listing it or deleting it)

Expected Behavior

I expect that operations to be working

Additional Context

No response

Are you willing to submit a PR to fix this bug?

• Yes, I would like to submit a PR.

[Xuanwo]

Thank you for the reports! We have a plan to add integration tests for this but not started yet. I believe we can add this as long as fixing them.

[vdudouyt]

@Frank-III thank you! If integration tests are still on the way, may I ask you to connect it with your FTP client and test some basic operations manually?

Currently, I can't even upload a file in root directory without error. And even with your PR fixes, whenever I chdir to Test directory, it gives me another directory with a strange name that looks like "--- -- --:-- OriginalDirName" in the list. Even if I chdir back to root, it still gives me that directory with a strange name. As per my understanding, the former happens because it presents me a list belonging to the root directory even if I chdir to Test/, and the latter happens because somehow it forgets the directory creation time.

[Frank-III]

Sorry, I may be wrong since I may not know this project better than you. it seems that the memory service does not support create_dir and all other dir related operations. I could reproduce this "--- -- --:-- OriginalDirName" issue, but I don't have any ideas

[Xuanwo]

I could reproduce this "--- -- --:-- OriginalDirName" issue, but I don't have any ideas

list will return itself, I'm guessing we need to filter itself will doing LIST.

[vdudouyt]

Sorry, I may be wrong since I may not know this project better than you. it seems that the memory service does not support create_dir and all other dir related operations. I could reproduce this "--- -- --:-- OriginalDirName" issue, but I don't have any ideas

I've just ensured that actually the memory service does support create_dir, but somehow it doesn't supports last_modified. I think that's exactly the reason why that hyphens occur preceeding the OriginalDirName, as I know that's exactly how unftp_sbe_opendal is working when last_modified is not available.

Although this doesn't explains why it appears even after chdir into the test directory itself, from what I have seen in the logs I got an impression that unftp_sbe_opendal always requests / from backend, even after chdir.

[vdudouyt]

@Frank-III finally I confirm it works without any problems with my custom OpenDAL service. Hope this will be merged in OpenDAL upstream.