Can not copy a file with a * to a CIFS mounted file

[Bob_165]

I'm copying a whole directory to a cifs mounted file system.
All the files and directories copy except those files that have a '*' in the file name.

For example:

cp -r -p 123*123 /test/

I get this error:

cp: cannot create /test/123*123: No such file or directory.

But of course I can copy this file to a local directory.

Very strange!

Anyone have any ideas?

[Pedro Cirne]

Hi,

Post here the output of "ls -al /test/", I've tested on my system to copy files with * to a cifs and it works!

Pedro

[Chris Vail]

Try cp -r -p 123\*123/test

Normally, the asterix (*) is expanded by the shell. If you want to use literally the asterix, you need to escape it by putting the backslash (\) in the charater in front of it.

Chris

[Bob_165]

Here's the output from

ls -al /test/
total 20
drwxrwxrwx 2 root sys 131072 Jul 18 09:01 .
drwxr-xr-x 27 root root 8192 Jul 18 08:20 ..
-rwxrwxrwx 1 root sys 7 Apr 29 12:57 bob.txt
-rwxrwxrwx 1 root sys 27 Apr 29 13:00 bob1

The reason I'm copying the directories and files is for a backup. There are close to 200 of these files ,all with * in the file name that won't copy.
Command I used to mount the cifs filesystem:
cifsmount "//ku2-2003.koretech.com/test_file" /test -Ubobb -PXXXX

The bobb user is a domain admin.
And I'm logged in as root on the HP-UX side.

[Bob_165]

Chris,

I'm copying serveral GB of data for the backup, not just one file and its just the file names with the * that doesn't copy.
I've tried two differnt HP-UX systems with different windows file systems and they both act the same way.
I was hoping there is some sort of hidden flag or option I could put on the cp or the mount command.
I've been goggleing for two days without any luck.

Pedro--can you tell me the command you used to mount your cifs file system? Any special security on the windows directoy?
Thanks--Bob

[Peter Nikitka]

Hi,

can you check, if any of these commands give errors as well:
1) no recursive copy
touch no-asterisk have'*'
cp no-asterisk /test/'with*'
cp 'have*' /tmp/

2) within a single directory
mkdir tt
touch tt/have'*'
cp -r tt /test

mfG Peter

[James R. Ferguson]

Hi Bob:

If you want to handle files with characters like "*" and spaces, enclose the filename in double quotes.

# touch "test*123"
# ls -l "test*123"
# rm "test*123"

Regards!

...JRF...

[Bob_165]

Peter,

Here's what I get:
/tmp # touch no-asterisk have*
/tmp # cp no-asterisk /test/
/tmp # cp have* /test/
cp: cannot create /test/have*: No such file or directory
/tmp # mkdir tt
/tmp # touch tt/have*
/tmp # cp -r tt /test/
cp: cannot create /test/tt/have*: No such file or directory

Still very strange!

[Bob_165]

What I doing is copying a directory that is serveral GB's with a few hundred files that have a * in the file name. There are more files with an * in there name created weekly.

So the bottomline is I can copy these files to a local directory but copying them to a CIFS mounted file system causes the errors.

It's almost like it's a bug in CIFS??

Pedro your's works; did you use some options on mounting the CIFS file system? Is your file system coming from a W2k3R2 system?

Thanks--Bob

[Bob_165]

One other note:

Even if I enclose it in "" it doesn't copy:

/tmp/bob # ls
123*123
/tmp/bob # cp -r -p "123*123" /test/
cp: cannot create /test/123*123: No such file or directory

[Peter Nikitka]

Hi,

this test
>>
/tmp # mkdir tt
/tmp # touch tt/have*
/tmp # cp -r tt /test/
cp: cannot create /test/tt/have*: No such file or directory
<<

shows clearly, that your remote filesystem does not allow the character '*' in a filename.

- Do you use a current CIFS version?
- Look at the SAMBA-configuration - best use swat - to get more info about possibilities: I remember about 'upcase' and similar parameters.

mfG Peter

[Dennis Handly]

The real question is why do you have "*" in filenames? These and spaces really really upset a shell.

If you need to, you can write a script to rename these evil files.

[Rasheed Tamton]

Did you try cp with escaping the asterisk

cp have\* /test

[Peter Nikitka]

Hey Rasheed,

Bob told already:
>>
Even if I enclose it in "" it doesn't copy:
<<
A backslash or single quotes don't differ.

Next: even when no '*' is used on the command line, this error message occurs.

@Dennis: So it would be nice NOT to have such filenames, admins often have no possibility in taking influence on applications and the people who use these to inhibit such names.

mfG Peter

[Dennis Handly · Accepted solution]

>Peter: admins often have no possibility in taking influence on applications and the people who use these to inhibit such names.

Just mention that "*" isn't valid on Windows, at least XP.

[Bob_165]

I think Dennis has the answer:
Indeed the '*' is not allowed in filenames in windows.

Unfortunately I have hundreds of these files. So now I know the problem....

Anyone have any ideas how to write a script to either escape these evil '*' or substitute another char during the cp command?

Thanks to all for your help so far!

[Peter Nikitka]

Hi,

using the attached skript 'rename_asterisk' shows this on my testdata. It substitutes 'X' for '*' - you can change this, if you like.
It takes care on directory structures nedding renamed at any level of its hierarchy.
Before:
ls -R yy
yy:
dir*1 dir*2 huhu

yy/dir*1:
f1

yy/dir*2:
f2*

yy/huhu:
f3*ee

Now use
rename_asterisk xx

and you get
ls -R yy
yy:
dirX1 dirX2 huhu

yy/dirX1:
f1

yy/dirX2:
f2X

yy/huhu:
f3Xee

[Bob_165]

Thanks Peter,

That's real close...Ideally I'd like to filter the cp (copy) command.

So it could look like

cp -r -p /source | filter * files | /destination/

I can't change the files at the source since these are active programs and screens being used in a live production environment.
Also, there are no directories that contain an * just files.

Thanks for your help!!!

[Chris Vail]

Have you considered using tar instead of cp? I've always found it handy:

cd $DIR
tar cvf - "$FNAME"\*"$EXT"|(cd $DDIR;tar xf -)

This allows you to have any filename or extension and move it. It uses a LOT of CPU horsepower though, but its blindingly quick.

Another thing you can do is create a text file with all the filenames in it: ls -1 $DIR>/tmp/tempfile, then use that file as an argument to tar command.

for i in `cat /tmp/tempfile`
do
tar cvf $i|(cd $DDIR|tar xf -)
done

or do it the uber-geek way
tar cvf `cat /tmp/tempfile`|(cd $DDIR;tar xf)

Tar will pick up all subdirectories, ownerships and permissions.

[Bob_165]

Chris,

Yes, I considered a tar file; but Iâ ve run into a size limit before with tar not being able to handle anything bigger than 2GB (I think there is a patch that will allow up to 8GB).
I have about 60GBâ s of data.

When you mentioned tar a light bulb just came on!

I tried using fbackup and frecover and it worked perfect!

Thanks to everyone!

[Bob_165]

See above..

[Dennis Handly]

>substitute another char during the cp command?

pax(1) will allow you to change the filenames when you extract.

>I've run into a size limit before with tar not being able to handle anything bigger than 2GB. I have about 60GB of data.

The tar limit is per file, not total.

>I tried using fbackup and frecover and it worked perfect!

I'm not sure how they fool windows?

[Eric Raeburn]

Bob,

I used work on the HP CIFS Client and just saw this thread. For what it's worth, this is what's going on: the CIFS Client filters out filenames that contain illegal DOS filename characters. So any filename with '*', '|', etc., gets rejected by the CIFS Client without even being sent to the server (you can see this behavior by looking at a network trace when attempting to copy a single file with an asterisk--no request is sent to the server for that file).

We once implemented an enhancement request to allow one of the illegal characters ('\'). You can even see the config parameter that turns this feature on and off (allowBackslashesInPaths). This worked because the servers were Linux and Unix. In theory, a similar enhancement could be done for '*', but due to the restrictions of the Windows filesystem, it would not solve your problem.

Glad you found a workaround.

-Eric