Support symlinks

[qwerty287]

Hello,
ftpserver does not support symlinks yet, they're just ignored. It would be very nice if it would be supported! Thank you!

[fclairamb]

Yes, very true. This needs to be implemented by adding this API.

[fclairamb]

@claude do you see how that could be done ?

[claude]

Claude finished @fclairamb's task —— View job

---

Analyzing Symlink Support Implementation

I can see how symlink support could be implemented in ftpserver. Let me break down the analysis:

Todo List:

• Read repository structure and CLAUDE.md
• Examine current driver implementation
• Analyze the ftpserverlib symlink API
• Identify integration points
• Provide implementation recommendations

Current Architecture Analysis

The ftpserver uses ftpserverlib v0.27.0 and implements a ClientDriver that currently only embeds afero.Fs (server/server.go:295-297):

type ClientDriver struct {
    afero.Fs
}

Implementation Approach

Based on the referenced API and the current architecture, here's how symlink support can be implemented:

1. Update ClientDriver Interface

The ClientDriver needs to implement the symlink methods from ftpserverlib's driver interface. Based on the referenced API at lines 83-90, these would be:

• Readlink(name string) (string, error) - Read the target of a symbolic link
• Symlink(oldname, newname string) error - Create a symbolic link

2. Implementation Strategy

// Add these methods to ClientDriver in server/server.go
func (c *ClientDriver) Readlink(name string) (string, error) {
    // Check if the underlying Fs supports symlinks (e.g., OsFs)
    if linker, ok := c.Fs.(interface{ Readlink(string) (string, error) }); ok {
        return linker.Readlink(name)
    }
    return "", os.ErrInvalid // or appropriate error for unsupported operation
}

func (c *ClientDriver) Symlink(oldname, newname string) error {
    // Check if the underlying Fs supports symlink creation
    if linker, ok := c.Fs.(interface{ Symlink(string, string) error }); ok {
        return linker.Symlink(oldname, newname)
    }
    return os.ErrInvalid // or appropriate error for unsupported operation
}

3. Backend Support Considerations

• Local OS FS: Full symlink support via underlying OS calls
• Cloud backends (S3, Dropbox, GDrive): Most don't support symlinks natively - would need to return appropriate errors
• SFTP: May support symlinks depending on the remote system

4. Key Integration Points

1. server/server.go:295-297 - Extend ClientDriver struct with symlink methods
2. fs/afos/afos.go - Likely needs symlink support for the OS filesystem backend
3. Individual FS backends - Each backend should handle symlinks appropriately

5. Implementation Steps

1. Add Readlink and Symlink methods to ClientDriver
2. Implement symlink support in the OS filesystem backend (fs/afos/)
3. Add appropriate error handling for backends that don't support symlinks
4. Test with local filesystem and ensure FTP clients can create/read symlinks

The approach leverages Go's interface duck typing to gracefully handle backends with and without symlink support, ensuring backwards compatibility while enabling symlink functionality where possible.

---

View branch changes

[martinlindhe]

Assuming Linux, here's some solutions that works today:

A) Run ftpserver in a container and mount volumes as you wish.

B) Use bind mounts. Requires you to edit /etc/fstab

C) Use bindfs. Requires no changes to fstab.

I use strategy A to make available a NAS share mounted on the host inside the ftpserver container, so i can reach it from a Windows XP vm. Works great!