constv: никто и не спорит, что SimpleDateFormat зависим от часового пояса. В таких случаях я делаю df.setTimeZone(TimeZone.getTimeZone("UTC")). Но в моем проблемном случае нет никакого форматирования. Мне нужно получить миллисекунды эпохи Unix, сохранить их в базу и потом отправить на сервер. А в результате получаю что-то необъяснимое...
Можете расшифровать свою мысль? Так как я всюду и так "гоняю" время по Гринвичу, а точнее в эпохе Unix. Вот только почему-то иногда я получаю значение смещенной эпохи. В этом и суть проблемы, про которую я написал.
Я написал программку, в которой по всякому издеваюсь с датой. У меня все нормально отработало, но у меня такого эффекта никогда и не было - завтра попробую на его телефоне...
Все же этот пользователь - мой директор и он сразу принес свой телефон. Так что злой умысел заподозрить трудно (разве что раздвоение личности). А вот на счет чувствительности даты к часовому поясу интересно. Все таки об этом классе упоминают как TimeZone-independence.
Я проверял - часовой пояс был наш - GMT+3. К тому же согласно документации объект даты предназначен для описания универсального времени, а потому конструктор и getTime() оперируют эпохой UNIX docs.oracle.com/javase/7/docs/api/java/util/Date.html
Пошел в правильном направлении и не дошел. Не пойму от куда мне пришла мысль, что пересчет должен быть из sp в dp? Попробовал значение задать явно как px и эту же цифру мне вернула getDimension(). СПАСИБО!
Suntechnic: если простого рецепта все же нет (хитрая опция в стандартном ftp-клиенте), то можно будет попробовать договорится. Но это, как говорится, уже будет совсем другая история...
Теоретически задача решаема. FXP (en.wikipedia.org/wiki/File_eXchange_Protocol) поверх обычного FTP позволяет сделать отправку с одного FTP-сервера на другой не заводя трафик на клиентскую машину. Только никак не могу разобраться: стандартный ftp-клиент Ubuntu (пришедший туда из BSD) умеет такое или нет? А если он не умеет, то могут ли другие программы из репозитория (с минимумом зависимостей) такое делать? На совсем левый "велосипед" с гитхаба я уже не пойду - чем проводить полный аудит кода проще смирится с удвоенным временем копирования.
Я ваш комментарий про SSH понял. Вы же вопрос читали? У меня желание уменьшить время копирования на удаленный сервер за счет отказа от двойного копирования одного и того же файла. SFTP - это реализация FTP поверх SSH, а в протоколе FTP (RFC 959) нет такой команды как скопировать из одного удаленного каталога в другой. А вот SCP поддерживает такое копирование. Касательно второй моей части ответа - SSH дают не всем. В моем случае с этим нужно смириться. В других случаях это мог вообще оказаться виндузный сервер и ssh тоже в пролете...
jcmvbkbc: после того, как все благополучно закончилось могу доложить, что проблема была не в initramfs, а в файле /usr/bin/find (из пакета findutils) , на который [скорее всего] припал один из бэдов винта.
Угадали верно - были такие варнинги. А ссылку я видел еще до написания вопроса и именно она меня толкнула на выполнение update-initramfs. Причина банальная - посыпался винт из программного рейда.
jcmvbkbc, вы так говорите, как будто это очевидное действие. Если бы в корне лежал этот файл, то я бы посмотрел нужную строку. Но в корне есть только /initrd.img который является ссылкой на /boot/initrd.img-3.0.0-12-server
gbg: когда я запускаю востановление с LiveCD, то мне удается запустить командную оболочку с корнем на устройстве /dev/md126 - визуально данные на месте.
@rusbaron, пишут верно. Но отключить насовсем парольную защиту я не хочу, так как обстоятельства меня могут застать в разных местах, а приватный ключ таскать на чужие компы не очень хорошая затея - проще воспользоваться паролем, а потом его сменить. Для защиты от брутфорса я сменил порт на очень нестандартный и включил fail2ban с настройкой на 3 попытки входа. Последнее из разряда дутья на воду, так как согласно логов еще ни один бот-нет не догадался на каком порту у меня теперь висит sshd.