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.

--
Regards,
Al S.

[Dave Yeo]

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

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

[Al Savage]

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]

--
Regards,
Al S.

[Steven Levine]

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

Hi Al,

> 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.

:-)

> 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.

> 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.

> [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.

> [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

--
---------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------

[Steven Levine]

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

Hi Dave,

> 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

[Al Savage]

On Thu, 14 Mar 2013 17:07:45 UTC, "Steven Levine"
<ste...@nomail.earthlink.net> wrote:

> 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.

> > 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.

> > [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.

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

Preserve permissions & timestamp, sure.

> > [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.

> 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
>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?

--
Regards,
Al S.

[Steven Levine]

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

Hi Al,

> That's the one I'm using.

OK.

> > 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.

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.

> >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.

> 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.

[Al Savage]

On Thu, 14 Mar 2013 19:30:15 UTC, "Steven Levine"
<ste...@nomail.earthlink.net> wrote:

> > [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.

> 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.

[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?

> 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.

> > 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).

--
Regards,
Al S.

[Steven Levine]

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

Hi,

> 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.

> > 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.

> [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.

> [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.

> 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.

[Paul Ratcliffe]

On Thu, 14 Mar 2013 15:17:10 -0500, Al Savage <asa...@iname.com> wrote:

> [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?

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
<ab...@orac12.clara34.co56.uk78> wrote:

> > 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

> 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.

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

Could be.

--
Regards,
Al S.

[Andreas Schnellbacher]

Al Savage wrote:

>>> SYS0317: The system cannot find message 0183
>

> 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

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.

--
Andreas Schnellbacher

[Al Savage]

On Fri, 15 Mar 2013 19:58:26 UTC, Andreas Schnellbacher
<as...@despammed.com> wrote:

> Al Savage wrote:
>
> >>> SYS0317: The system cannot find message 0183
> >
> > 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
>
> 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.

> 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?

--
Regards,
Al S.

[Steven Levine]

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

Hi Al,

> Isn't it odd?

Not really. It's all about parentage.

> 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

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

[Al Savage]

On Fri, 15 Mar 2013 21:53:35 UTC, "Steven Levine"
<ste...@nomail.earthlink.net> wrote:

> > 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
>
> 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.

--
Regards,
Al S.