Tip: don't use a space at the end of the file name!

Hi All,

Todd made a boo-boo.

I set up a Cobian Backup task. I was backing up into
a directory called:
%DISKLABEL="BACKUP":\MyDocsBackup\backup1

I kept getting two getting two identical directories
called "backup1". Both were empty. Cobian said it
definitely did copy files to it.

So in Windows Explorer (Not IE), I erased both of them.
Two seconds after they both disappeared, a single
"backup1" came back and this time it had files in it.
What the hell?

After a bunch of head scratching, I discovered
that I had put a space at the end of
"%DISKLABEL="BACKUP":\MyDocsBackup\backup1 "
-----------------------------------------------^

Removed the space and happy camping returned.

I don't think I will forget that one for a lot
of years!

-T

T on 2017/01/20 wrote:

I set up a Cobian Backup task. I was backing up into
a directory called:
%DISKLABEL="BACKUP":\MyDocsBackup\backup1

I kept getting two getting two identical directories
called "backup1". Both were empty. Cobian said it
definitely did copy files to it.

So in Windows Explorer (Not IE), I erased both of them.
Two seconds after they both disappeared, a single
"backup1" came back and this time it had files in it.
What the hell?

After a bunch of head scratching, I discovered
that I had put a space at the end of
"%DISKLABEL="BACKUP":\MyDocsBackup\backup1 "
-----------------------------------------------^

Removed the space and happy camping returned.

So it is a problem in parsing in Cobian, not of Windows (which would've
ignored the trailing space). I don't know how Cobian uses variables
which seems to be what you used in the above example line. If Cobian
was using the equivalent of the command-line 'set' command along with
variable substitution then it probably just passes the string to the
'set' command as-is which includes any and all leading and trailing
spaces.

Try the following in a command shell where ^ represents a space
character:

set aaa=^^^there^^^
set bbb=hello%aaa%everyone
echo %bbb%

On 01/20/2017 05:15 PM, VanguardLH wrote:
T on 2017/01/20 wrote:

I set up a Cobian Backup task. I was backing up into
a directory called:
%DISKLABEL="BACKUP":\MyDocsBackup\backup1

I kept getting two getting two identical directories
called "backup1". Both were empty. Cobian said it
definitely did copy files to it.

So in Windows Explorer (Not IE), I erased both of them.
Two seconds after they both disappeared, a single
"backup1" came back and this time it had files in it.
What the hell?

After a bunch of head scratching, I discovered
that I had put a space at the end of
"%DISKLABEL="BACKUP":\MyDocsBackup\backup1 "
-----------------------------------------------^

Removed the space and happy camping returned.

So it is a problem in parsing in Cobian, not of Windows (which would've
ignored the trailing space). I don't know how Cobian uses variables
which seems to be what you used in the above example line. If Cobian
was using the equivalent of the command-line 'set' command along with
variable substitution then it probably just passes the string to the
'set' command as-is which includes any and all leading and trailing
spaces.

Try the following in a command shell where ^ represents a space
character:

set aaa=^^^there^^^
More?
set bbb=hello%aaa%everyone
More?
echo %bbb%
hello%aaa%everyone

I don't get it. :'(

T on 2017/01/20 wrote:

On 01/20/2017 05:15 PM, VanguardLH wrote:
T on 2017/01/20 wrote:

I set up a Cobian Backup task. I was backing up into
a directory called:
%DISKLABEL="BACKUP":\MyDocsBackup\backup1

I kept getting two getting two identical directories
called "backup1". Both were empty. Cobian said it
definitely did copy files to it.

So in Windows Explorer (Not IE), I erased both of them.
Two seconds after they both disappeared, a single
"backup1" came back and this time it had files in it.
What the hell?

After a bunch of head scratching, I discovered
that I had put a space at the end of
"%DISKLABEL="BACKUP":\MyDocsBackup\backup1 "
-----------------------------------------------^

Removed the space and happy camping returned.

So it is a problem in parsing in Cobian, not of Windows (which would've
ignored the trailing space). I don't know how Cobian uses variables
which seems to be what you used in the above example line. If Cobian
was using the equivalent of the command-line 'set' command along with
variable substitution then it probably just passes the string to the
'set' command as-is which includes any and all leading and trailing
spaces.

Try the following in a command shell where ^ represents a space
character:

set aaa=^^^there^^^
More?
set bbb=hello%aaa%everyone
More?
echo %bbb%
hello%aaa%everyone

I don't get it. :'(

You did not replace the ^ (carat) characters with spaces as you were
warned. Again, "^ represents a space character." So do that in the
example command lines.

On Fri, 20 Jan 2017 19:15:22 -0600
VanguardLH wrote:

I don't know how Cobian uses variables

Then STFU

On 01/20/2017 09:51 PM, VanguardLH wrote:
T on 2017/01/20 wrote:

On 01/20/2017 05:15 PM, VanguardLH wrote:
T on 2017/01/20 wrote:

I set up a Cobian Backup task. I was backing up into
a directory called:
%DISKLABEL="BACKUP":\MyDocsBackup\backup1

I kept getting two getting two identical directories
called "backup1". Both were empty. Cobian said it
definitely did copy files to it.

So in Windows Explorer (Not IE), I erased both of them.
Two seconds after they both disappeared, a single
"backup1" came back and this time it had files in it.
What the hell?

After a bunch of head scratching, I discovered
that I had put a space at the end of
"%DISKLABEL="BACKUP":\MyDocsBackup\backup1 "
-----------------------------------------------^

Removed the space and happy camping returned.

So it is a problem in parsing in Cobian, not of Windows (which would've
ignored the trailing space). I don't know how Cobian uses variables
which seems to be what you used in the above example line. If Cobian
was using the equivalent of the command-line 'set' command along with
variable substitution then it probably just passes the string to the
'set' command as-is which includes any and all leading and trailing
spaces.

Try the following in a command shell where ^ represents a space
character:

set aaa=^^^there^^^
More?
set bbb=hello%aaa%everyone
More?
echo %bbb%
hello%aaa%everyone

I don't get it. :'(

You did not replace the ^ (carat) characters with spaces as you were
warned. Again, "^ represents a space character." So do that in the
example command lines.


Hi Vanguard,

I still don't get why you are using the carat escape character
"^" to represent a space.

Oh I get it. That was for me to replace. I though you
meant it literaly. I thought you were escaping something.
The tip should have been that there was three of them

-T

T on 2017/01/21 wrote:

On 01/20/2017 09:51 PM, VanguardLH wrote:
T on 2017/01/20 wrote:

On 01/20/2017 05:15 PM, VanguardLH wrote:
T on 2017/01/20 wrote:

I set up a Cobian Backup task. I was backing up into
a directory called:
%DISKLABEL="BACKUP":\MyDocsBackup\backup1

I kept getting two getting two identical directories
called "backup1". Both were empty. Cobian said it
definitely did copy files to it.

So in Windows Explorer (Not IE), I erased both of them.
Two seconds after they both disappeared, a single
"backup1" came back and this time it had files in it.
What the hell?

After a bunch of head scratching, I discovered
that I had put a space at the end of
"%DISKLABEL="BACKUP":\MyDocsBackup\backup1 "
-----------------------------------------------^

Removed the space and happy camping returned.

So it is a problem in parsing in Cobian, not of Windows (which would've
ignored the trailing space). I don't know how Cobian uses variables
which seems to be what you used in the above example line. If Cobian
was using the equivalent of the command-line 'set' command along with
variable substitution then it probably just passes the string to the
'set' command as-is which includes any and all leading and trailing
spaces.

Try the following in a command shell where ^ represents a space
character:

set aaa=^^^there^^^
More?
set bbb=hello%aaa%everyone
More?
echo %bbb%
hello%aaa%everyone

I don't get it. :'(

You did not replace the ^ (carat) characters with spaces as you were
warned. Again, "^ represents a space character." So do that in the
example command lines.


I still don't get why you are using the carat escape character
"^" to represent a space.

Oh I get it. That was for me to replace. I though you
meant it literaly. I thought you were escaping something.
The tip should have been that there was three of them

What do you use as a placeholder character for another that is
invisible? If I had used underscores, those typically meld into each
other so you couldn't see how many space characters I used in the
example. I suppose I could have doubled the lines and shown the command
line with another under it with carats showing where are the spaces but
then you might've tried entering those lines as commands.

On 01/21/2017 01:53 PM, VanguardLH wrote:
T on 2017/01/21 wrote:

On 01/20/2017 09:51 PM, VanguardLH wrote:
T on 2017/01/20 wrote:

On 01/20/2017 05:15 PM, VanguardLH wrote:
T on 2017/01/20 wrote:

I set up a Cobian Backup task. I was backing up into
a directory called:
%DISKLABEL="BACKUP":\MyDocsBackup\backup1

I kept getting two getting two identical directories
called "backup1". Both were empty. Cobian said it
definitely did copy files to it.

So in Windows Explorer (Not IE), I erased both of them.
Two seconds after they both disappeared, a single
"backup1" came back and this time it had files in it.
What the hell?

After a bunch of head scratching, I discovered
that I had put a space at the end of
"%DISKLABEL="BACKUP":\MyDocsBackup\backup1 "
-----------------------------------------------^

Removed the space and happy camping returned.

So it is a problem in parsing in Cobian, not of Windows (which would've
ignored the trailing space). I don't know how Cobian uses variables
which seems to be what you used in the above example line. If Cobian
was using the equivalent of the command-line 'set' command along with
variable substitution then it probably just passes the string to the
'set' command as-is which includes any and all leading and trailing
spaces.

Try the following in a command shell where ^ represents a space
character:

set aaa=^^^there^^^
More?
set bbb=hello%aaa%everyone
More?
echo %bbb%
hello%aaa%everyone

I don't get it. :'(

You did not replace the ^ (carat) characters with spaces as you were
warned. Again, "^ represents a space character." So do that in the
example command lines.


I still don't get why you are using the carat escape character
"^" to represent a space.

Oh I get it. That was for me to replace. I though you
meant it literaly. I thought you were escaping something.
The tip should have been that there was three of them

What do you use as a placeholder character for another that is
invisible? If I had used underscores, those typically meld into each
other so you couldn't see how many space characters I used in the
example. I suppose I could have doubled the lines and shown the command
line with another under it with carats showing where are the spaces but
then you might've tried entering those lines as commands.



I never use a space at the end of a name. If I want spaces
inside the name, I just use a space. I also use dots a lot and
sometimes an underscore.

Linux would be "\ ". No clue about Windows

T on 2017/01/23 wrote:

On 01/21/2017 01:53 PM, VanguardLH wrote:
T on 2017/01/21 wrote:

On 01/20/2017 09:51 PM, VanguardLH wrote:
T on 2017/01/20 wrote:

On 01/20/2017 05:15 PM, VanguardLH wrote:
T on 2017/01/20 wrote:

I set up a Cobian Backup task. I was backing up into
a directory called:
%DISKLABEL="BACKUP":\MyDocsBackup\backup1

I kept getting two getting two identical directories
called "backup1". Both were empty. Cobian said it
definitely did copy files to it.

So in Windows Explorer (Not IE), I erased both of them.
Two seconds after they both disappeared, a single
"backup1" came back and this time it had files in it.
What the hell?

After a bunch of head scratching, I discovered
that I had put a space at the end of
"%DISKLABEL="BACKUP":\MyDocsBackup\backup1 "
-----------------------------------------------^

Removed the space and happy camping returned.

So it is a problem in parsing in Cobian, not of Windows (which would've
ignored the trailing space). I don't know how Cobian uses variables
which seems to be what you used in the above example line. If Cobian
was using the equivalent of the command-line 'set' command along with
variable substitution then it probably just passes the string to the
'set' command as-is which includes any and all leading and trailing
spaces.

Try the following in a command shell where ^ represents a space
character:

set aaa=^^^there^^^
More?
set bbb=hello%aaa%everyone
More?
echo %bbb%
hello%aaa%everyone

I don't get it. :'(

You did not replace the ^ (carat) characters with spaces as you were
warned. Again, "^ represents a space character." So do that in the
example command lines.


I still don't get why you are using the carat escape character
"^" to represent a space.

Oh I get it. That was for me to replace. I though you
meant it literaly. I thought you were escaping something.
The tip should have been that there was three of them

What do you use as a placeholder character for another that is
invisible? If I had used underscores, those typically meld into each
other so you couldn't see how many space characters I used in the
example. I suppose I could have doubled the lines and shown the command
line with another under it with carats showing where are the spaces but
then you might've tried entering those lines as commands.


I never use a space at the end of a name. If I want spaces
inside the name, I just use a space. I also use dots a lot and
sometimes an underscore.

Linux would be "\ ". No clue about Windows

Depends on the parser. For regex, that be "\s", "\s*", "s+", or with
other repeat qualifiers (obviously without the double quotes), or even
"\s$" to denote at the end of the line and "^\s" at the start of the
line? Even C uses quotes to delimite a string constant. So it's a
problem with parser seeing a space character that your eyes do not. The
parser goes to the EOL character (or NUL to terminate a string in C) so
it picks up anything before that as part of the string, including
characters invisible to your eye (and why some malware will insert a DEL
character in a string that you cannot see, not even a placeholder for it
when displayed).