rsync: Invalid argument (22) on copy to a Samba server share

[Al Savage]

I'm not sure that this is the correct place to ask this . . . but it
doesn't seem to rise to the level of a bug, yet, until someone more
knowledgable says it is.

In the example below,
rsync version is 3.0.9 shl
F: is a local drive on an eCS 2.1 box;
V: is a LAN Warp Server Advanced share
Z: is a NAS4Free (FreeBSD) Samba share
The file "temp.txt" does not exist at the destination.
Copying from local to WSA:
[C:\programs\rsync]rsync f:\temp\temp.txt z:\x\

[C:\programs\rsync]rsync f:\temp\temp.txt z:\x\

Result: the file is copied to dest first run. Nothing occurs second
run, as --update is not specified, and the file isn't newer on source
anyway.)

Copying from local to NAS:
[C:\programs\rsync]rsync f:\temp\temp.txt z:\x\

[C:\programs\rsync]rsync f:\temp\temp.txt z:\x\
rsync: rename "z:/x/.temp.txt.EmotUo" -> "temp.txt": Invalid argument
(22)
rsync error: some files/attrs were not transferred (see previous errors)
(code 2
3) at main.c(1176) [sender=3.0.9]

The file is copied to dest first run. The second (and subsequent) runs
always produce this error. Options I've tried with no change:

--update
-X
--os2-perms

I found this initially by looking at the logs that luckybackup produces.
rsync is not updating any files copied to the NAS that *already exist*
on the NAS. But backing out options one-by-one, I realized that it's
not an update problem after all, as even when a file does not need to be
updated, the "Invalid argument (22)" occurs.

[Dave Yeo]

Post by Al Savage
[C:\programs\rsync]rsync f:\temp\temp.txt z:\x\

What about using f:/temp/temp.txt z:/x/
Dave

[Al Savage]

Post by Dave Yeo

Post by Al Savage
[C:\programs\rsync]rsync f:\temp\temp.txt z:\x\

What about using f:/temp/temp.txt z:/x/

Exactly the same text is returned:
rsync: rename "z:/x/.temp.txt.EmotUo" -> "temp.txt": Invalid argument
(22)
rsync error: some files/attrs were not transferred (see previous errors)
(code 23) at main.c(1176) [sender=3.0.9]

[Steven Levine]

On Thu, 14 Mar 2013 04:36:05 UTC, Dave Yeo <***@gmail.com>
wrote:

Hi Dave,

Post by Dave Yeo
What about using f:/temp/temp.txt z:/x/

The rsync port does the right thing for slashes. I does not always
handle LIBC pathrewrites correctly, because the klibccfg.dll is not
fork compliant.

rsync -itp f:\temp\temp.txt z:\x

is probably what Al really wants. If the NAS understands OS/2
permissions and EAs, this can be

rsync -itpX2 f:\temp\temp.txt z:\x

Steven

[Steven Levine]

On Thu, 14 Mar 2013 03:35:06 UTC, "Al Savage" <***@iname.com>
wrote:

Hi Al,

Post by Al Savage
I'm not sure that this is the correct place to ask this . . . but it
doesn't seem to rise to the level of a bug, yet, until someone more
knowledgable says it is.

:-)

Post by Al Savage
rsync version is 3.0.9 shl

Which 3.0.9? There have been more than a few 3.0.9 builds. rsync
--version will tell you. The most recent build is

rsync version 3.0.9 protocol version 31 (os2-perms)
Copyright (C) 1996-2011 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Built by Steven H. Levine Dec 21 2012 10:43:12
Built with GCC 4.4.7
Capabilities:
64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, no IPv6, batchfiles, inplace,
append, no ACLs, xattrs, iconv, symtimes

rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and
you
are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details.

Post by Al Savage
F: is a local drive on an eCS 2.1 box;
V: is a LAN Warp Server Advanced share
Z: is a NAS4Free (FreeBSD) Samba share

None of this should matter, but it appears you may have a Samba or NAS
issue. Analysis will tell more.

Post by Al Savage
[C:\programs\rsync]rsync f:\temp\temp.txt z:\x\
Result: the file is copied to dest first run. Nothing occurs second
run, as --update is not specified, and the file isn't newer on source
anyway.)

This is not true. With above options, you are basically using rsync
as a copy replacement. The file will be copied every time, which is
clearly not what you expected. The -i option is your friend.

When copying to a NAS, you probably want to use at least -t -p.

Post by Al Savage
[C:\programs\rsync]rsync f:\temp\temp.txt z:\x\
rsync: rename "z:/x/.temp.txt.EmotUo" -> "temp.txt": Invalid argument
(22)

There is something non-obvious failing. Try the command line
equivalent

copy f:\temp\temp.txt z:\x\.temp.txt.EmotUo
rename z:\x\.temp.txt.EmotUo temp.txt

Also

rsync -ivvvvvvvv f:\temp\temp.txt z:\x\

might provide some clues.

Steven

[Al Savage]

On Thu, 14 Mar 2013 17:07:45 UTC, "Steven Levine"

Post by Steven Levine
Which 3.0.9? There have been more than a few 3.0.9 builds. rsync
--version will tell you. The most recent build is
rsync version 3.0.9 protocol version 31 (os2-perms)

That's the one I'm using.

Post by Steven Levine

Post by Al Savage
F: is a local drive on an eCS 2.1 box;
V: is a LAN Warp Server Advanced share
Z: is a NAS4Free (FreeBSD) Samba share

None of this should matter, but it appears you may have a Samba or NAS
issue. Analysis will tell more.

Sure, that's my assumption too, as I don't see this error when working
with local OS/2 LAN drives.

Post by Steven Levine

Post by Al Savage
[C:\programs\rsync]rsync f:\temp\temp.txt z:\x\
Result: the file is copied to dest first run. Nothing occurs second
run, as --update is not specified, and the file isn't newer on source
anyway.)

This is not true. With above options, you are basically using rsync
as a copy replacement. The file will be copied every time, which is
clearly not what you expected. The -i option is your friend.

OK.
I began with a very option-laden line that was giving the error, and
one-by-one I removed options until I had the minimum testcase.

Post by Steven Levine
When copying to a NAS, you probably want to use at least -t -p.

Preserve permissions & timestamp, sure.

Post by Steven Levine

Post by Al Savage
[C:\programs\rsync]rsync f:\temp\temp.txt z:\x\
rsync: rename "z:/x/.temp.txt.EmotUo" -> "temp.txt": Invalid argument
(22)

There is something non-obvious failing. Try the command line
equivalent
copy f:\temp\temp.txt z:\x\.temp.txt.EmotUo
rename z:\x\.temp.txt.EmotUo temp.txt

That works when no z:\x\temp.txt is present, but after it's been copied
in place once, of course the rename op doesn't work:

[C:\programs\rsync]copy f:\temp\temp.txt z:\x\.temp.txt.EmotUo
1 file(s) copied.

[C:\programs\rsync]rename z:\x\.temp.txt.EmotUo temp.txt
SYS0317: The system cannot find message 0183
in message file OSO001.MSG.

Post by Steven Levine
Also
rsync -ivvvvvvvv f:\temp\temp.txt z:\x\
might provide some clues.

===========================================
[C:\programs\rsync]rsync -ivvvvvvvv f:\temp\temp.txt z:\x\
FILE_STRUCT_LEN=16, EXTRA_LEN=4
cmd=<NULL> machine=<NULL> user=<NULL> path=z:/x/
cmd[0]=. cmd[1]=z:/x/
note: iconv_open("IBM-850", "IBM-850") succeeded.
(Client) Protocol versions: remote=30, negotiated=30
(Server) Protocol versions: remote=30, negotiated=30
[sender] change_dir(f:/temp)
[sender] make_file(temp.txt,*,0)
[sender] flist start=0, used=1, low=0, high=0
[sender] i=0 f:/temp temp.txt mode=0100666 len=2749 flags=0
send_file_list done
file list sent
send_files starting
server_recv(2) starting pid=208
received 1 names
[Receiver] flist start=0, used=1, low=0, high=0
[Receiver] i=0 1 temp.txt mode=0100666 len=2749 flags=0
recv_file_list done
get_local_name count=1 z:/x/
[Receiver] change_dir(z:/x)
generator starting pid=208
recv_files(1) starting
delta-transmission disabled for local transfer or --whole-file
recv_generator(temp.txt,0)
temp.txt times differ sender 1363229888 receiver 1363282360
send_files(0, f:/temp/temp.txt)
count=0 n=0 rem=0
send_files mapped f:/temp/temp.txt of size 2749
calling match_sums f:/temp/temp.txt

Post by Steven Levine
f..T...... temp.txt

sending file_sum
false_alarms=0 hash_hits=0 matches=0
sender finished f:/temp/temp.txt
send_files phase=1
generate_files phase=1
recv_files(temp.txt)
recv mapped temp.txt of size 2749
data recv 2749 at 0
got file_sum
renaming .temp.txt.ggH6WZ to temp.txt
rsync: rename "z:/x/.temp.txt.ggH6WZ" -> "temp.txt": Invalid argument
(22)
recv_files phase=1
generate_files phase=2
send_files phase=2
send_files finished
total: matches=0 hash_hits=0 false_alarms=0 data=2749
recv_files phase=2
generate_files phase=3
recv_files finished
generate_files finished
client_run waiting on 208

sent 2821 bytes received 31 bytes 1901.33 bytes/sec elapsed 00:00:01
total size is 2749 speedup is 0.96
[sender] _exit_cleanup(code=0, file=main.c, line=1176): entered
rsync error: some files/attrs were not transferred (see previous errors)
(code 2
3) at main.c(1176) [sender=3.0.9]
[sender] _exit_cleanup(code=0, file=main.c, line=1176): about to call
exit(23)
===========================================

Why the protocol=30 ? Shouldn't that be 31?

[Steven Levine]

On Thu, 14 Mar 2013 17:42:32 UTC, "Al Savage" <***@iname.com>
wrote:

Hi Al,

Post by Al Savage
That's the one I'm using.

OK.

Post by Al Savage

Post by Steven Levine
copy f:\temp\temp.txt z:\x\.temp.txt.EmotUo
rename z:\x\.temp.txt.EmotUo temp.txt

That works when no z:\x\temp.txt is present, but after it's been copied
[C:\programs\rsync]copy f:\temp\temp.txt z:\x\.temp.txt.EmotUo
1 file(s) copied.
[C:\programs\rsync]rename z:\x\.temp.txt.EmotUo temp.txt
SYS0317: The system cannot find message 0183
in message file OSO001.MSG.

You have a install nit of some sort. What you should get is

[j:\tmp\0]cmd /c ren tmp.txt tmp1.txt
SYS1083: A duplicate file name exists, the file cannot be found, or
the file is being used.

IAC, this is not quite the right test. Rsync is going to use unix
semantics for the rename. A unix rename is more like an OS/2 move.

Let's see what

copy f:\temp\temp.txt z:\x\.temp.txt.EmotUo
z:
cd x
move z:\x\.temp.txt.EmotUo temp.txt

does. This is closer to what a rsync does with a unix-style rename.

FYI, rsync does not use a naive rename. It uses a wrapper called
robust_rename(). If the rename fails with

#define EACCES 13 /* Permission denied */

the destination is changed to r/w and the operation is retried. The
error you are getting

#define EINVAL 22 /* Invalid argument */

is caused by something else.

Post by Al Savage

Post by Steven Levine
f..T...... temp.txt

sending file_sum
false_alarms=0 hash_hits=0 matches=0
sender finished f:/temp/temp.txt
send_files phase=1
generate_files phase=1
recv_files(temp.txt)
recv mapped temp.txt of size 2749
data recv 2749 at 0
got file_sum
renaming .temp.txt.ggH6WZ to temp.txt
rsync: rename "z:/x/.temp.txt.ggH6WZ" -> "temp.txt": Invalid argument
(22)

This is all normal until the error 22. I have some ideas what might
be going on, but it's going to be a couple of days before I can devote
significant time to this although I will be around to responds to
newgroup posts.

Post by Al Savage
Why the protocol=30 ? Shouldn't that be 31?

This is all explained in readme.shl. If not, I will need to do some
rewriting.

Steven

[Al Savage]

On Thu, 14 Mar 2013 19:30:15 UTC, "Steven Levine"

Post by Steven Levine

Post by Al Savage
[C:\programs\rsync]rename z:\x\.temp.txt.EmotUo temp.txt
SYS0317: The system cannot find message 0183
in message file OSO001.MSG.

You have a install nit of some sort.

I have two W4 boxes and one eCS box here, and all three exhibit that
same error message in that situation. I really have no idea how to fix
that nit, but it's been a low priority for years.

Post by Steven Levine
Let's see what
copy f:\temp\temp.txt z:\x\.temp.txt.EmotUo
cd x
move z:\x\.temp.txt.EmotUo temp.txt
does. This is closer to what a rsync does with a unix-style rename.

[C:\programs\rsync]copy f:\temp\temp.txt z:\x\.temp.txt.EmotUo
1 file(s) copied.

[C:\programs\rsync]z:

[Z:\]cd x

[Z:\x]move z:\x\.temp.txt.EmotUo temp.txt
SYS0317: The system cannot find message 0183
in message file OSO001.MSG.
0 file(s) moved.

Just for fun, I tried it on a local drive:

[F:\temp]copy f:\temp\temp.txt f:\temp\.temp.txt.EmotUo
1 file(s) copied.

[F:\temp]move f:\temp\.temp.txt.EmotUo temp.txt
SYS1083: A duplicate file name exists, the file cannot be found, or
the file is being used.
0 file(s) moved.

Hey, now the message file lookup works. What gives?

Post by Steven Levine
FYI, rsync does not use a naive rename. It uses a wrapper called
robust_rename(). If the rename fails with
#define EACCES 13 /* Permission denied */
the destination is changed to r/w and the operation is retried. The
error you are getting
#define EINVAL 22 /* Invalid argument */
is caused by something else.

Post by Al Savage
Why the protocol=30 ? Shouldn't that be 31?

This is all explained in readme.shl. If not, I will need to do some
rewriting.

Ah, I re-read that, and I suppose that I'm seeing a drop-back to
protocol 30 when I do not use --os2-perms (which I always do, except
when testing like we are here).

[Steven Levine]

On Thu, 14 Mar 2013 20:17:10 UTC, "Al Savage" <***@iname.com>
wrote:

Hi,

Post by Al Savage
I have two W4 boxes and one eCS box here, and all three exhibit that
same error message in that situation. I really have no idea how to fix
that nit, but it's been a low priority for years.

:-) An we shall let it stay that way.

Post by Al Savage

Post by Steven Levine
Let's see what
copy f:\temp\temp.txt z:\x\.temp.txt.EmotUo
cd x
move z:\x\.temp.txt.EmotUo temp.txt
does. This is closer to what a rsync does with a unix-style rename.

[Z:\x]move z:\x\.temp.txt.EmotUo temp.txt
SYS0317: The system cannot find message 0183
in message file OSO001.MSG.
0 file(s) moved.

So it does. I keep forgetting how brain-dead cmd.exe is. I need to
come up with a better testcase.

Post by Al Savage
[F:\temp]move f:\temp\.temp.txt.EmotUo temp.txt
SYS1083: A duplicate file name exists, the file cannot be found, or
the file is being used.
0 file(s) moved.
Hey, now the message file lookup works. What gives?

Probably a DPATH issue.

Post by Al Savage
Ah, I re-read that, and I suppose that I'm seeing a drop-back to
protocol 30 when I do not use --os2-perms (which I always do, except
when testing like we are here).

Basically, although It's the other way around. 3.0.9 uses protocol by
default. Protocol 31 is an extension to properly handle OS/2
permissions. The original implementation of --os2-perms attempted to
use protcol 30, but it could not always do the right thing.

Steven

[Paul Ratcliffe]

Post by Al Savage
[Z:\x]move z:\x\.temp.txt.EmotUo temp.txt
SYS0317: The system cannot find message 0183
in message file OSO001.MSG.
0 file(s) moved.
[F:\temp]copy f:\temp\temp.txt f:\temp\.temp.txt.EmotUo
1 file(s) copied.
[F:\temp]move f:\temp\.temp.txt.EmotUo temp.txt
SYS1083: A duplicate file name exists, the file cannot be found, or
the file is being used.
0 file(s) moved.
Hey, now the message file lookup works. What gives?

1083 != 0183

Guys, you REALLY need to read exactly what is written, not what you
think is written.

I would guess 0183 is the result of some funky error code from Samba
on NAS4Free.

[Al Savage]

On Fri, 15 Mar 2013 10:20:35 UTC, Paul Ratcliffe

Post by Paul Ratcliffe

Post by Al Savage
SYS0317: The system cannot find message 0183
SYS1083: A duplicate file name exists, the file cannot be found, or
the file is being used.

1083 != 0183

You have to admit, that's an easy one to confuse ;)

Isn't it odd?
0183 in M$-speak is:

183L ERROR_ALREADY_EXISTS
Attempt to create file that already exists.

Semantically, pretty much the same.
IOW, OS/2 1083 == M$ 0183

Post by Paul Ratcliffe
Guys, you REALLY need to read exactly what is written, not what you
think is written.

I'm a lazy reader, when I think I'm reading something that doesn't
matter much.

Post by Paul Ratcliffe
I would guess 0183 is the result of some funky error code from Samba
on NAS4Free.

Could be.

[Andreas Schnellbacher]

SYS0317: The system cannot find message 0183

183L ERROR_ALREADY_EXISTS Attempt to create file that already
exists.
Semantically, pretty much the same. IOW, OS/2 1083 == M$ 0183

Do you really think that OS/2 queries the error code from your M$
router over network? Turn on your brain. Esp. after Paul told you what
to do.

[Al Savage]

On Fri, 15 Mar 2013 19:58:26 UTC, Andreas Schnellbacher

Post by Andreas Schnellbacher

SYS0317: The system cannot find message 0183

183L ERROR_ALREADY_EXISTS Attempt to create file that already
exists.
Semantically, pretty much the same. IOW, OS/2 1083 == M$ 0183

Do you really think that OS/2 queries the error code from your M$
router over network?

No, I don't think that.
I think that the result of my conflating one error number with another
is that they really do appear to be the same -- over *very* similar --
error message. Odd, but true, for this one particular case. I find
that amusing.

Post by Andreas Schnellbacher
Turn on your brain. Esp. after Paul told you what to do.

Paul told me to read. That's what I did. What have I missed, Andreas?

[Steven Levine]

On Fri, 15 Mar 2013 18:20:11 UTC, "Al Savage" <***@iname.com>
wrote:

Hi Al,

Post by Al Savage
Isn't it odd?

Not really. It's all about parentage.

Post by Al Savage
183L ERROR_ALREADY_EXISTS
Attempt to create file that already exists.
Semantically, pretty much the same.
IOW, OS/2 1083 == M$ 0183

Once you correct your typo, they are exactly the same. :-)

The reason is that errors 0 to 18 were defined for DOS. IBM and MS
added errors 19 to 487 or so while they were developing OS/2. When
they became not so friendly, MS dropped the codes they didn't need for
their kernels.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms681382%28v=v
s.85%29.aspx

is a list of MS's codes as of some point in time. \toolkit\h\bseerr.h
is a list of what is defined for OS/2

Steven

[Al Savage]

On Fri, 15 Mar 2013 21:53:35 UTC, "Steven Levine"

Post by Steven Levine

Post by Al Savage
183L ERROR_ALREADY_EXISTS
Attempt to create file that already exists.
Semantically, pretty much the same.
IOW, OS/2 1083 == M$ 0183

Once you correct your typo, they are exactly the same. :-)

Hmmm. What typo? Oh, I see.

[C:\programs\rsync]move z:\x\.temp.txt.EmotUo temp.txt
SYS0317: The system cannot find message 0183
in message file OSO001.MSG.
0 file(s) moved.

[C:\programs\rsync]move f:\temp\.temp.txt.EmotUo temp.txt
SYS1083: A duplicate file name exists, the file cannot be found, or
the file is being used.
0 file(s) moved.