Нет, это не делает насколько я знаю. Но можно всегда использовать mkdir -p
и touch
друг после друга:
f="/a/b/c.txt"
mkdir -p -- "${f%/*}" && touch -- "$f"
Это поведение легко объяснено через размер буфера вывода и настройки окна TCP.
Во-первых, при получении данных, у Вас или есть биты, или Вы не делаете. Ваше локальное scp
знает, сколько это ожидает и сколько это получило до сих пор, таким образом, это может дать Вам точную оценку прогресса и оцененное время, оставаясь.
При отправке данных у Вас нет информации о том, сколько из тех данных на самом деле достигло получателя все же. Ваша локальная машина будет иметь буфер вывода, который содержит данные после того, как это было "отправлено" приложением (scp) и прежде чем это будет на самом деле передано в сети. Кроме того, TCP позволяет определенному количеству данных быть "в полете" между отправителем и получателем.
При отправке данных, scp
только видит, сколько это передало к ОС для возможной передачи. Заполнение буферов вывода происходит действительно быстро, так вот почему scp
измеряет высокую скорость передачи первоначально. В то время как передача прогрессирует, это значение сходится к реальной скорости передачи. После того, как Вы передали все данные к своей ОС, они все еще должны достигнуть другой стороны, и вот почему это, кажется, застревает в 100% в течение нескольких секунд в конце.
Современные сети OSes и TCP увеличили размер окна TCP (см., что окно TCP масштабирует опцию), составлять "длинные толстые сети" и с широкой полосой пропускания и с высокой задержкой. Именно поэтому можно видеть, что это поведение чаще, чем Вы имеет в прошлом.
Недавно я столкнулся с очень похожей проблемой, когда WireShark показывал ошибки TCP ZeroWindow всякий раз, когда я пытался передавать данные по ssh со скоростью, превышающей определенную. Наконец-то я проследил это до того, что на моем маршруте что-то напортачило с обработкой качества обслуживания IP. Добавление этой конфигурации в мою конфигурацию sshd _и конфигурацию ssh _исправило это:
IPQoS=af21 cs1
Эти настройки будут использоваться по умолчанию в более новой версии SSH, чем у меня сейчас:https://www.openssh.com/txt/release-7.8
ioctl
сSIOCOUTQ
должен получить объем буферизированных данных. По крайней мере, согласно документам вtcp(7)
, на самом деле не попробовали его. Ноscp
не может сделать этого, с тех порssh
на самом деле обрабатывает сокет. – derobert 30.03.2015, 17:35