Mauro Molinari ---
I'm also encountering problems regarding mkstemp "file name too long error"
when rsyncing to an ecryptfs filesystem. Probably, rsync should try to handle
this in a smarter way.
A secondary problem I see is that, even if this error is given, the whole file
is t
https://bugzilla.samba.org/show_bug.cgi?id=11978
--- Comment #2 from Syr ---
Triple post. Shouldn't it also use e.g. f_namelen from statfs() at runtime
instead of a compile-time constant?
And MAXPATHLEN doesn't even seem to reflect reality, since it's not actually
limited to that on Linux.
https
https://bugzilla.samba.org/show_bug.cgi?id=11978
--- Comment #1 from Syr ---
https://git.samba.org/rsync.git/?p=rsync.git;a=blob;f=receiver.c;hb=3267d6a9ceeefad438080b17c02daa7775820803#l143
Wait, it actually adds 8 characters to it in total, there's a dot prepended at
the beginning to.
--
You
https://bugzilla.samba.org/show_bug.cgi?id=11978
Bug ID: 11978
Summary: mkstemp failed: File name too long (36) when filename
is under the limit
Product: rsync
Version: 3.1.1
Hardware: All
OS: All
Hello,
I suggest you to download new Long Path Tool software that simply allows you
to work easily on Long Path files.
Thank you.
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Bef
On Fri, 2012-03-30 at 12:49 +0200, Paul Slootman wrote:
> The problem is that your OS doesn't accept the long filenames;
> there's nothing that rsync can do to fix your OS.
Hey Paul. That's something I should have thought of already, given that
I am a developer, and I apologize for not having cons
On Thu 29 Mar 2012, Kip Warner wrote:
>
> Some file names are very long and rsync unfortunately cannot transfer
> them, issuing the following error message:
>
> failed: File name too long (78)
>
> I'm assuming the 78 is drawn from a system header that it was compiled
Hey list,
I am using rsync version 3.0.7, protocol version 30, to transfer data
between amd64 and mipsel machines, tunnelled over SSH.
Some file names are very long and rsync unfortunately cannot transfer
them, issuing the following error message:
failed: File name too long (78)
I'm ass
Hi,
cwRsync 1.3.0 users - I have compiled a new version of rsync executable that
includes a post-2.6.4 patch, addressing 'Multiplexing Overflows when File
Name Too Long'. See thread
http://www.mail-archive.com/rsync@lists.samba.org/msg13003.html for more
info. Thanks to Benjamin
Benjamin Watkins wrote:
I will let you know how the patch works for me. I am currently
running it from Workstation 1 to Server 1.
After more extensive testing with this patch, I can confirm that it does
indeed resolve this issue for me under Cygwin.
If Tev repackages his cwRsync package, I wou
Wayne Davison wrote:
On Fri, Apr 01, 2005 at 03:54:38PM -0500, Benjamin Watkins wrote:
multiplexing overflow 1:296 [sender]
This indicates that there is an error message arriving (1) that has a
length of 296 bytes, but this is too long for the "line" buffer in
readfd_unbuffered(). I change
On Fri, Apr 01, 2005 at 03:54:38PM -0500, Benjamin Watkins wrote:
> multiplexing overflow 1:296 [sender]
This indicates that there is an error message arriving (1) that has a
length of 296 bytes, but this is too long for the "line" buffer in
readfd_unbuffered(). I changed the length of this buffe
Benjamin Watkins wrote:
Benjamin Watkins wrote:
So far this observation has been made on one out of one clients that
I have tested. I was able to repeat this error several times on this
machine before I discovered the message in the server log pointing me
to the long file name problem. I am ru
Benjamin Watkins wrote:
So far this observation has been made on one out of one clients that I
have tested. I was able to repeat this error several times on this
machine before I discovered the message in the server log pointing me
to the long file name problem. I am running a test from anothe
moved).000679" (in backup) failed: File name too long (91)
2005/04/01 13:01:43 [365] (various other files being backed up, all with
same timestamp)
2005/04/01 13:01:43 [365] rsync: writefd_unbuffered failed to write 12
bytes: phase "unknown" [generator]: Connection reset by peer (104)
Comitted to cvs.
--
J.W. SchultzPegasystems Technologies
email address: [EMAIL PROTECTED]
Remember Cernan and Schmitt
--
To unsubscribe or change options: http://lists.samba.or
On Wed, Mar 12, 2003 at 12:23:30PM +0100, Paul Slootman wrote:
> On Wed 12 Mar 2003, jw schultz wrote:
> >
> > Not quite final. I really didn't like calling strcpy for
> > single chars so i fixed that. Also strlcpy counts the null
>
> I was thinking of this, but I'm optimistic that gcc will unr
On Wed 12 Mar 2003, jw schultz wrote:
>
> Not quite final. I really didn't like calling strcpy for
> single chars so i fixed that. Also strlcpy counts the null
I was thinking of this, but I'm optimistic that gcc will unroll such
things...
> in the length so a small adjustment had to be made.
On Wed, Mar 12, 2003 at 10:27:38AM +0100, Paul Slootman wrote:
> On Tue 11 Mar 2003, jw schultz wrote:
> >
> > I threw this out there because it looked like we were
> > heading towards a rewrite of the whole function and i wanted
> > to rethink it instead of just reworking parts of it. If a
> > c
On Tue 11 Mar 2003, jw schultz wrote:
>
> I threw this out there because it looked like we were
> heading towards a rewrite of the whole function and i wanted
> to rethink it instead of just reworking parts of it. If a
> concensus is that this is the way to go i'm all for that.
> If the pointer a
A 20:02 11/03/2003 +0100, Paul Slootman a écrit :
On Tue 11 Mar 2003, Luc Santeramo wrote:
> A 16:19 11/03/2003 +0100, Paul Slootman a écrit :
> >On Tue 11 Mar 2003, Luc Santeramo wrote:
> >
> >> maybe you can send me receiver.c ?
> >
> >Done.
>
> ok I got it
> but maybe I should wait for you and
On Tue 11 Mar 2003, Luc Santeramo wrote:
> A 16:19 11/03/2003 +0100, Paul Slootman a écrit :
> >On Tue 11 Mar 2003, Luc Santeramo wrote:
> >
> >> maybe you can send me receiver.c ?
> >
> >Done.
>
> ok I got it
> but maybe I should wait for you and JW to agree on this part ?
Well, it's basically
A 16:19 11/03/2003 +0100, Paul Slootman a écrit :
On Tue 11 Mar 2003, Luc Santeramo wrote:
> maybe you can send me receiver.c ?
Done.
ok I got it
but maybe I should wait for you and JW to agree on this part ?
Luc
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
On Tue, Mar 11, 2003 at 03:45:05PM +0100, Paul Slootman wrote:
> On Tue 11 Mar 2003, jw schultz wrote:
> >
> > Hmm. I'm thinking we should just build fnametmp a piece at
> > a time. I coded it up to see how it would look. Not as
> > intuitive but there is a lot less strlen and no snprintf.
> >
On Tue 11 Mar 2003, Luc Santeramo wrote:
> maybe you can send me receiver.c ?
Done.
Paul Slootman
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
For some reason patch doesn't recognize what to patch.
I think the easiest way is to get the rsync package I uploaded to the
Debian unstable branch this morning. Until it shows up in the archive,
you can get it here:
http://people.debian.org/~paul/rsync_2.5.6-0.1_i386.deb
The dependencies are libc
On Tue 11 Mar 2003, Luc Santeramo wrote:
> Hi,
>
> when I try to patch I got
>
> # patch -p0 < file_name_too_long.diff
> patching file rsync-2.5.6/receiver.c
> Hunk #1 FAILED at 166.
> 1 out of 1 hunk FAILED -- saving rejects to file rsync-2.5.6/receiver.c.rej
>
> am I doing something wrong?
Fo
On Tue 11 Mar 2003, jw schultz wrote:
>
> Hmm. I'm thinking we should just build fnametmp a piece at
> a time. I coded it up to see how it would look. Not as
> intuitive but there is a lot less strlen and no snprintf.
> It also deals shortens the filename both for MAXPATHLEN and
> for NAME_MAX
Hi,
when I try to patch I got
# patch -p0 < file_name_too_long.diff
patching file rsync-2.5.6/receiver.c
Hunk #1 FAILED at 166.
1 out of 1 hunk FAILED -- saving rejects to file rsync-2.5.6/receiver.c.rej
am I doing something wrong?
thanks
Luc
With this patch, I can successfully transfer a file
On Tue, Mar 11, 2003 at 10:47:10AM +0100, Paul Slootman wrote:
> On Tue 11 Mar 2003, jw schultz wrote:
> >
> > That or char fscratch[MAXPATHLEN];
> > Just don't use malloc.
>
> How about this:
>
>
> static int get_tmpname(char *fnametmp, char *fname)
> {
> char*f;
> char*dir
On Tue 11 Mar 2003, jw schultz wrote:
>
> That or char fscratch[MAXPATHLEN];
> Just don't use malloc.
How about this:
static int get_tmpname(char *fnametmp, char *fname)
{
char*f;
char*dir = ""; /* what dir to put the temp file in */
charnamepart[NAME_MA
On Tue, Mar 11, 2003 at 09:51:42AM +0100, Paul Slootman wrote:
> On Tue 11 Mar 2003, jw schultz wrote:
> > On Tue, Mar 11, 2003 at 09:16:24AM +0100, Paul Slootman wrote:
> > > >
> > > > The one thing that bothers me, also present in the current
> > > > code is the bit of changing and then restorin
On Tue 11 Mar 2003, jw schultz wrote:
> On Tue, Mar 11, 2003 at 09:16:24AM +0100, Paul Slootman wrote:
> > >
> > > The one thing that bothers me, also present in the current
> > > code is the bit of changing and then restoring fname. That
> > > complicates the code in ways that are prone to induc
On Tue, Mar 11, 2003 at 09:16:24AM +0100, Paul Slootman wrote:
> On Mon 10 Mar 2003, jw schultz wrote:
> >
> > Overall it looks like it should be an improvement. Getting
> > rid of all that code duplication is a real gain.
> >
> > The one thing that bothers me, also present in the current
> > co
On Tue, Mar 11, 2003 at 09:11:41AM +0100, Paul Slootman wrote:
> On Mon 10 Mar 2003, jw schultz wrote:
>
> > Please reply to the list.
>
> Note that you have a
> Mail-Followup-To: jw schultz <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> header in your messages, so that mutt's reply to list will still
On Mon 10 Mar 2003, jw schultz wrote:
>
> Overall it looks like it should be an improvement. Getting
> rid of all that code duplication is a real gain.
>
> The one thing that bothers me, also present in the current
> code is the bit of changing and then restoring fname. That
> complicates the c
On Mon 10 Mar 2003, jw schultz wrote:
> Please reply to the list.
Note that you have a
Mail-Followup-To: jw schultz <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
header in your messages, so that mutt's reply to list will still want to
CC you... I removed your address anyway...
> > we need to "wget" a
With this patch, I can successfully transfer a file that has a 255-char
filename.
Ok, thanks Paul.
I'll try this patch.
Only thing that may be a problem is the NAME_MAX thing, but that's a
POSIX thing, so should be relatively safe (famous last words).
wget uses URL name to create directories and s
Please reply to the list.
On Mon, Mar 10, 2003 at 05:05:40PM +0100, Luc Santeramo wrote:
> A 03:53 10/03/2003 -0800, vous avez écrit :
> >On Mon, Mar 10, 2003 at 11:08:57AM +0100, Luc Santeramo wrote:
> >> Hi,
> >>
> >> I've got a File name too long pro
On Mon, Mar 10, 2003 at 05:09:56PM +0100, Paul Slootman wrote:
> On Mon 10 Mar 2003, jw schultz wrote:
> >
> > What you have done is hit a file created by something insane
> > where the filename is 252 characters long. Adding the
> > prepended . and the appended .XX made it 260 characters
> >
On Mon 10 Mar 2003, jw schultz wrote:
>
> What you have done is hit a file created by something insane
> where the filename is 252 characters long. Adding the
> prepended . and the appended .XX made it 260 characters
> long and the filesystem doesn't support that long a name.
Correct analysi
On Mon, Mar 10, 2003 at 11:08:57AM +0100, Luc Santeramo wrote:
> Hi,
>
> I've got a File name too long problem using rsync-2.5.6 or rsync 2.5.5-0.1
> (debian)
>
> I had a look to the mailing list archive and to the todo file and all I've
> seen was that the prob
Hi,
I've got a File name too long problem using rsync-2.5.6 or rsync 2.5.5-0.1
(debian)
I had a look to the mailing list archive and to the todo file and all I've
seen was that the problem only appears on old special systems.
I'm using debian 2.2.20. (is it too old?)
I've
43 matches
Mail list logo
