| delorie.com/archives/browse.cgi | search |
Tomasz Chmielewski schrieb: > James Abley schrieb: > > (...) > >> I've just tried the current snapshot and most (all?) of my problems >> with long path names have gone away, whereas the main release was >> failing at the start of the month. >> >> Previously: >> >> 2008/03/07 20:47:05 [13024] rsync: readlink >> "/AppData/Local/Application Data/Application Data/Application >> Data/Application Data/Application Data/Application Data/Application >> Data/A >> pplication Data/Application Data/Application >> Data/Adobe/Acrobat/8.0/Cache/Search80/08695a9e61055471bbeac6c64c29faa3.idx" >> >> (in jabley) failed: File name too long (91) >> >> But using the current snapshot, rsync (2.6.9) has been fine with the >> long path names. There are some issues (hey, it's a snapshot!) which >> I'll report separately, but I'm pretty happy! > > Hmm, I'm not happy any more. > > For me, rsync.exe 2.6.9-2 from Cygwin can't read long path names with > the latest cygwin1.dll snapshot. > > cwRsync (3.0.0) however, can read long filenames with the latest > cygwin1.dll snapshot. > > > And there is more to it: neither rsync.exe 2.6.9-2 from Cygwin nor > cwRsync (3.0.0) can read long path names when rsync is started as a > Windows service (cygrunsrv 1.34-1). False alarm... It will fail i.e. with --protocol=28 (used by BackupPC). It will not fail if protocol is omitted - rsync 3.0.0 uses protocol 30. -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |