Uzun dosya adlarını destekleyen Windows rsync veya iyi bir alternatif mi?


13

Şu anda bir Linux ana bilgisayarında rsync'i Windows'tan Linux kutusuna kopyalamak için. Ancak uzun adlara sahip dosyaları kopyalayamıyorum.

Ben denedim DeltaCopy , cwRsync ve cygwin . Bulduğumdan, tüm bu dosyalar dosyanın uzunluğu uzadığında dosyaları kopyalamayı reddediyor, bu 255 karakter civarında bir yerde görünüyor.

Bu sorun cwRsync forumlarında ele alınmaktadır burada ve 1.7 çıkıyor ve cygwin UTF8 desteklendiği zaman sözde gelecekte bazen sabitlenebilir. Burada bir test kurumu bile var .

Bir üretim sistemi üzerindeki test yapısını kullanmaktan özellikle rahat değilim. Birisinin başka bir rsync seçeneğini bilmesini umuyorum.

Rsync'e alternatif olarak, Linux'ta bir dizin yapısını uzun veya olağandışı adlandırılmış dosyalarla sorun yaşamayan bir Windows ana bilgisayarından kopyalayabildiğim başka bir araç biliyor musunuz? Önemli olan, bir SSH tünelinde kolayca çalışabilecek bir araca ihtiyacım olması. Bazı sistemler güvenlik duvarlarının ötesinde ve SSH'nin kullanmam için izin vereceğim tünel olduğuna inanıyorum.


FYI cwrsync, uzun dosya adlarını destekleyen cygwin 1.7 tabanlı bir güncelleme yayımladı! itefix.no/i2/node/12070
Zoredache

Yanıtlar:


6

Bu noktayı kaçırıyor olabilirim ama Windows'ta Robocopy kullanmayı düşündünüz mü ? RSync'e benzer, ancak doğrudan uygulamadan zamanlayamazsınız.

Bu, kopya için bir toplu iş dosyası yazıp ardından Zamanlanmış Görev oluşturarak aşılabilir. Robokopi ücretsizdir ve son derece sağlamdır. Genellikle Samba ve ağ kullanarak Linux ve Windows arasında dosya kopyalamak için kullanıyorum ve Robocopy'nin özgeçmiş kapasitesi gerçekten güçlü.


robocopy düşündüğüm bir seçenektir, ancak yanlış yönde çalışır (galibiyetten lin'e doğru itin), Linux'ta pencerelerden çekmek istedim. Daha iyi bir şey bulamazsam bu yöne gitmem gerekebileceğinden şüpheleniyorum.
Zoredache

5

Aha! Rsync ile sub kullanabilirsiniz.

Derin bir dizin ağacınız varsa d: \ very \ long \ file \ n \ ame \ etc \ etc, sonra deney: X: 'ı d: \ very \ long \ file \ name \ etc' ye ve sonra rsync ve / cygdrive / x / türünden. Bu, hem istemci tarafında hem de sunucu tarafında çalışır.

Artık 260 karakter sınırını atlamanıza izin verip vermediğini bilmediğim dosya adlarının uzunluğunu azaltmak için stratejik alt öğeler kullanabilirsiniz. Ayrıca çok uygun olmayabilir. Yine de denemeye değer.

John Rennie.

---- 8 <----

Uzun dosya adlarındaki haydutlarım için http://www.ratsauce.co.uk/notablog/LongFilenames.asp adresine bakın .

Cygwin'e \\? \ Önekini almanın bir yolunu bilmiyorum ve tabii ki Cygwin'in mevcut sürümü öneki dahili olarak kullanmıyor. Muhtemelen yeni versiyonda bunu ele alıyorlar ve bu yüzden 260 karakterden uzun isimleri destekleyecek. Cygwin rsync'i her yerde kullanıyorum, böylece sizin gibi serbest bırakılmayı sabırsızlıkla bekliyorum.

Cygwin rsync ile ilgili başka sorunlar da var. Cygwin = nontsec belirtmediğiniz sürece ACL'leri karıştırır ve çok büyük dizinlerde asılı kalma eğilimindedir. Ölmeden önce yapılacaklar listemde, bu sorunlara sahip olmayan bir rsync yerel Windows sürümü yazmaktır. Bunun yapıldığına inanıyorum, ancak sadece ticari sürümler olarak kamu malı değil.

JR


Önce tüm dosyaları okumak zorunda olduğu için Rsync büyük dizinlerde asılı görünüyor. Sorun, önce tüm dosyaları okur, sonra rsync devreye girer. Orada kaç dosya olduğuna bağlı olarak dizini taramak için birkaç dakika sürebilir.
Ryaner

Artık rsync 3.0'da durum böyle değil. Artık dosyaları daha erken göndermeye başlayabilmesi için artımlı bir dosya listesi gönderir.
James Sneeringer

2

Unison'u denemenizi öneririm http://www.cis.upenn.edu/~bcpierce/unison/

Rsync'e çok ilginç bir alternatiftir, çünkü aynı zamanda iki yönlü senkronizasyon da sağlayabilir (rsync bunu yapamaz). Zaten 2 sanal makinede başarıyla kullandım ve sonuçlardan çok memnun kaldım.

Ancak dosya adı ile ilgili olarak, istediğiniz gibi çalışıp çalışmadığını bilmiyorum.

Resmi web sitesinden:

Unison, Unix ve Windows için bir dosya senkronizasyon aracıdır. Bir dosya ve dizin koleksiyonunun iki kopyasının farklı ana bilgisayarlarda (veya aynı ana bilgisayardaki farklı disklerde) depolanmasına, ayrı olarak değiştirilmesine ve daha sonra her çoğaltmadaki değişiklikleri diğerine geçirerek güncel duruma getirilmesine izin verir.


250 karakterden daha uzun yollarla kullandınız mı? Windows üzerinde almanın tek yolu cygwin üzerinden görünüyor, ki bu da cygwin rsync ile yaşadığım aynı konuya sahip olacağı anlamına geliyor.
Zoredache

Uzun yolu test etmedim, ancak Windows için Unison ikili dosyaları cygwin.dll (ikili dosyalarla birlikte gelir, cygwin'i yüklemeye gerek yoktur) kullanılarak oluşturulur, bu nedenle düzgün çalışabilir. Deneyin :)
Olivier Jaquemet

2

Sadece aynı sorunla karşılaştığım (1.7 öncesi cygwin sınırlamaları) ve burada cygwin 1.7 ile çalışan bir cwrsync yapısı bulduğum bir not:

http://www.doering-thomas.de/page.php?seite=1&sub=6&lang=en#rsync

(Orijinal bağlantı cwrsync forumlarında bulundu)

Tam olarak resmi bir yapı değil, ancak karakter sorunlarımı çözdü :)


1

http://lists.samba.org/archive/rsync/2009-March/022955.html

http://www.okisoft.co.jp/esc/utf8-cygwin/ Olası yol boyutunu artırma yan etkisi olan bir UTF8 katmanı vardır. Yazara göre, daha fazla karakter kullanmak istiyorsanız, yamadaki sabiti yükseltebilirsiniz. Bu daha da acayip görünüyor.

Muhtemelen uzaktan senkronizasyon için en iyi bahsiniz değil, daha uzun dosya adlarını desteklediğini iddia eden bir windows rsync.


Bu yazı beni biraz endişelendiriyor ( cygwin.com/ml/cygwin/2006-05/msg00068.html ) - "Temel olarak, çoğu yeni olan 930 satırlık bir yama var. FWICS, Unicode'un bulunduğu tüm yerleri kapsamıyor olabilir dönüşüm gerekebilir (özellikle, bir metin modu borusu üzerinden Unicode göndermek büyük olasılıkla başarısız olacaktır)
Zoredache

0

Peki, Windows'ta araçlar kötüyse Linux aracını kullanmanın bir yolu var mı?

Ssh - sshfs ile mi?

Ssh olmadan - bir VPN kullanın ve SMB olarak mı monte edilir?

Her iki şekilde de, bir dosya sistemine karşı daha yetenekli Linux rsync istemcisini kullanmanıza izin verir. Bunu 10GB veriyle yapmadım, bu yüzden YMMV. :)


Pencerelerden dosyaları Linux kutuma çekmeye çalışıyorum. Ayrıca, haftalık olarak senkronize etmek istediğim 10GB + 'dan fazla veriyle konuştuğum için gerçekten bir arşiv oluşturmak istemiyorum. Bir arşiv oluşturursam, artan güncellemelerden faydalanmayacağım.
Zoredache

Tamam, düzeltilmiş cevap.
Cawflands

0

Bu, büyük dosya yapıları yapmaz, ancak uzun adlara sahip nispeten küçük veri kümeleri için, rsync'in aktarabileceği bir arşiv oluşturmak için 7-Zip gibi bir şey kullanabilirsiniz. Windows sunucularından bir Linux sunucusuna veri çekmeniz gerektiğini söylediniz. Kabuk erişiminiz varsa, ihtiyacınız olan verileri bir kapta arşivleyin (7-zip) kabı aktarın ve sunucuya ulaştığında genişletin. Bu, uzun dosya adı sorununu daha iyi destek ve Cygwin olmayan araçlar olduğuna inandığım arşivleyiciye iter.


0

Taşınabilirliği kaybetmemek için rsync ile kalmanızı ve 255 sınırlamasını çözmeye çalışmanızı tavsiye ederim. Bu sınırlama artık Windows içinde değil ve RSYNC kodunda - aslında Windows'daki sınır 2048 civarında (iyi hatırlıyorsam).

Sizin tarafınızdan belirtilenlerden başka rsync bağlantı noktası olmadığından eminim ve test sürümünü kullanmanızı ve bulabileceğiniz hataları bildirmenizi öneririm.

FTP kullanmanın sakıncası yoksa LFTP'yi deneyebilirsiniz - çok iyi bir yansıtma özelliğine sahiptir, ancak yedekleme / senkronizasyon söz konusu olduğunda rsync ile karşılaştırılmaz.


0

Ben birlikte bir senaryo kesmek rsync (ve diğer programlar) sürdürebilmesi için geçici olarak kısa adları ile dosyaları veya dizinleri yeniden adlandırabilirsiniz. Bunu, dosyaları Linux'tan Windows'a (rsync veya başka türlü) kopyalamak için kullandığınız araç zincirinin bir parçası olarak kullanabilirsiniz. "Olağandışı" ile ne demek istediğinizi bilmiyorum, bu yüzden bu sadece gereksinimlerinizin bir kısmını ele alıyor. Lütfen size yardımcı olup olmadığını bildirin.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.