Two design comments: I noticed that firefox starts writing the file
'foo' as 'foo.part' and then renames it at the end.
I like this approach precisely because it is *not* hidden. Users aren't
dumb. They'll figure it out and they can better manage problems they can
see. Hidden files are probably just asking for trouble.
I'm slightly uncomfortable with the assumptions that the auxillary
filename will be valid and that the final rename() operation is going to
be cheap, or even available. It may be that the user wants to copying
files into a virtual filesystem, where files have special semantics
based on their name (eg /dev/). Or that the filesystem is something that
doesn't support rename very well (eg a live-burning CD fs).
I think also you may be interested in a previous discussion on whether
sftp is a file transfer protocol or a filesystem protocol.
d
Thomas Blank wrote:
> Darren Tucker wrote:
>
>> Do you have control over the clients? If so:
>>
>> 3. Use sftp to upload the file with a temporary name then rename it when
>> it's complete. Something like this (untested):
>>
>> sftp -b /dev/stdin server.example.com << EOD
>> put myfile.txt .myfile.txt
>> rename .myfile.txt myfile.txt
>> EOD
>>
>
> No, I do not have control over the clients.
> Jefferson's suggestion of using tunneled rsnc is therefore also not possible.
> Implementing this is much more work as using standard sftp-commands in a
> script.
>
> inotify may help but I'm using Solaris not Linux - although not knowing but
> inotify may not have been ported to Solaris.
>
> Any other suggestions?
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
|