Closed romanrm closed 8 years ago
Hi,
Yes, seeks within files opened in write mode are not supported, see the limitations section in the documentation.
Gateways to OVH Public Cloud Storage supporting sftp
, rsync
and scp
are available as a free beta test, but you need a PCS account in the GRA1 region to use them.
As a HubiC user, you can try my fork of OpenSSH that brings a sftp-server
version avoiding seeks.
Thanks! I have installed your sftp-server, and now SFTP works.
For those, who still wanna use whatever sftp they have with lseek, this workaround might help you in some edge cases:
./.foo
and rename for ./foo
after upload is finish
(example proftpd: like HiddenStores on
)So use local disk for sftp, and use rsync with SWIFT like:
MOUNT_DIR=/mnt/foo
TEMP_DIR=$(mktemp -d)
rsync -avh \
-A --no-perms \
--temp-dir=${TEMP_DIR} \
--remove-source-files \
--exclude=".*" \
/var/spool/ftp/ \
${MOUNT_DIR}
--remove-source-files
- remove file(s) from local sftp dir, but after proper moving to SWIFT
--temp-dir=${TEMP_DIR}
- skip lseek on SWIFT and do that job in temp dir
--exclude=".*"
- skip temporary files - user currently do the uploads
Hello,
Using svfs 0.7.4 with HubiC;
I need to use a file synchronization program ('sitecopy') which only supports FTP, SFTP or WebDAV. For that reason I mount the FUSE filesystem, then access it via a SFTP, FTP or WebDAV server.
This works fine with hubicfuse; however with svfs all uploads fail, even though I tried all possible variants of SFTP, WebDAV or FTP. The best piece of debug output which could hint to the cause which I could obtain, is from vsftpd:
Seems like the root cause is always the same, the 'lseek' function returns an error on svfs. And files I am trying to sync get created, but have zero size and a failure is reported to the client. So, aside from regular 'cp' or 'rsync' many programs won't work properly when writing to svfs.
Do you think there can be any workaround for this limitation?
Ideally svfs itself could provide gateway to WebDAV, or even HubiC could support WebDAV directly (but that's probably dreaming too much...)