A WebDAV monitor and delivery processor would be great. I frequently use the FTP processor for monitoring and delivering. The addition of WebDAV support would really open FFAStrans to monitor and deliver to a huge range of places e.g. Nextcloud, pCloud & NAS. Some places support both FTP and WebDAV but it's my understanding that WebDAV is slightly faster and more secure than FTP.
My use case is I want to deliver files to pCloud but they don't support FTP, only WebDAV.
WebDAV support
Re: WebDAV support
Hey Ben,
you know, ffastrans "just" utilizes lots of existing commandline tools to get the work done. So you can imagine that it will not happen that all used tools will be altered in a way that they support other sources than "block device" natively.
The only possible way how to deal with this kind of stuff is to "mount" the target in a way that "any application" can work with it.
Especially for WebDAV, there are many tutorials out there how to use it as a network drive, so it should not be a really big issue for you to do this.
The only really big caveat is the case when you want to run ffastrans as a service, because in that case, mapped network drives are not of help in first place - instead you have to know how to map the drive for the running ffastrans job using a commandline executor or similar.
In fact it should not be a big issue to work on WebDAV, S3, or whatever protocol... all of them typically deliver some tools to map them as a "network drive" in windows.
Lemme know any doubts!
you know, ffastrans "just" utilizes lots of existing commandline tools to get the work done. So you can imagine that it will not happen that all used tools will be altered in a way that they support other sources than "block device" natively.
The only possible way how to deal with this kind of stuff is to "mount" the target in a way that "any application" can work with it.
Especially for WebDAV, there are many tutorials out there how to use it as a network drive, so it should not be a really big issue for you to do this.
The only really big caveat is the case when you want to run ffastrans as a service, because in that case, mapped network drives are not of help in first place - instead you have to know how to map the drive for the running ffastrans job using a commandline executor or similar.
In fact it should not be a big issue to work on WebDAV, S3, or whatever protocol... all of them typically deliver some tools to map them as a "network drive" in windows.
Lemme know any doubts!
emcodem, wrapping since 2009 you got the rhyme?
Re: WebDAV support
Hey emcodem,
Yeah that all sounds quite fair. I didn't know you could map WebDAV using a command line executor. I shall look into that. Thanks!
Yeah that all sounds quite fair. I didn't know you could map WebDAV using a command line executor. I shall look into that. Thanks!
Re: WebDAV support
Hi all!
we've moved from SSHFS to WebDAV because of mounting purpose.
But it seems we have similar problem.
WebDAV is mounted on Windows server 2016 as Q: drive.
But we always get the same error "The system cannot find the path specified" when trying to deliver a file via "FOLDER" processor.
Where the destination is written like this: Q:\VOD\
Thanks!
we've moved from SSHFS to WebDAV because of mounting purpose.
But it seems we have similar problem.
WebDAV is mounted on Windows server 2016 as Q: drive.
But we always get the same error "The system cannot find the path specified" when trying to deliver a file via "FOLDER" processor.
Where the destination is written like this: Q:\VOD\
Thanks!
Re: WebDAV support
Hey @veks,
as mentioned above, it depends a lot if you run ffastrans as service or as logged in user. I guess as service, so you have to understand that Q: or any other mapped network drive does not exist for ffastrans because mapped drives are visible for the current user's session only and there is no way around that. When running as service you either have to figure something out that maps the drive for the service's session (a cmd proc which maps the drive letter) or use UNC paths.
as mentioned above, it depends a lot if you run ffastrans as service or as logged in user. I guess as service, so you have to understand that Q: or any other mapped network drive does not exist for ffastrans because mapped drives are visible for the current user's session only and there is no way around that. When running as service you either have to figure something out that maps the drive for the service's session (a cmd proc which maps the drive letter) or use UNC paths.
emcodem, wrapping since 2009 you got the rhyme?
Re: WebDAV support
But for example, SSHFS-Win-Manager maps it as a drive/local disk.
But then only for FFAStrans I get access denied.
But then only for FFAStrans I get access denied.
Re: WebDAV support
@veks
as far as i see, SSHFS-Win-Manager utilizes winfsp which is similar to Fuse Filesystem driver, this is a totally different thing than the mentioned webdav stuff. I have no real experience with that. However, what you want to do is to log in with the same user as ffastrans service is running (for that the service credentials can NOT be "System" but you have to explicitly use some existing username). Then you make sure that whatever you access, works without a password prompt popping up in windows explorer.
Still that way, you can not work with "mapped drives" but maybe you have a chance at least accessing stuff via FUSE driver using UNC paths.
However, all these obscure file access methods generate huge efforts and usually also run pretty instable, i wonder why you don't just use Samba Server if you want to access linux filesystems?
as far as i see, SSHFS-Win-Manager utilizes winfsp which is similar to Fuse Filesystem driver, this is a totally different thing than the mentioned webdav stuff. I have no real experience with that. However, what you want to do is to log in with the same user as ffastrans service is running (for that the service credentials can NOT be "System" but you have to explicitly use some existing username). Then you make sure that whatever you access, works without a password prompt popping up in windows explorer.
Still that way, you can not work with "mapped drives" but maybe you have a chance at least accessing stuff via FUSE driver using UNC paths.
However, all these obscure file access methods generate huge efforts and usually also run pretty instable, i wonder why you don't just use Samba Server if you want to access linux filesystems?
emcodem, wrapping since 2009 you got the rhyme?