The Samba-Bugzilla – Bug 2769
Windows clients can't handle dotfile filenames with two trailing spaces
Last modified: 2005-09-29 07:40:06 UTC
As the summary states, windows clients (at least 2000) can't handle filenames
with two trailing spaces.
For example, create the file ".foo\<space>\<space>", then try to copy it using
explorer. It will work fine in smbclient, but explorer will report a "Cannot
copy from source disk" error.
However, the filename of ".foo" will work just fine.
Correction: I spoke too soon. This seems to occur on ANY file name with a space
after the .extention part.
Including (but probably not limited too);
Again, grapeshot accordingly if already reported or fixed.
Can you catagorise the names that need to be mangled and I'll add them to the
mangling rules on the server.
Hmm. Not sure I quite get what you mean but...
I think it boils down to; "Filenames with trailing spaces".
even foo\<space> inclusive.
In fact, windows mistakes these files for folders when I try to copy them from
When you add a space to the end of a filename in windows it says: "Cannot rename
file, source and destination are the same", and when you rename a file and add a
space at the end, it just trims the space.
I suspect spaces are used internally in NTFS to indicate folders.
Sorry if I'm being too verbose, I just hate vauge bug reports.
What I mean is it's not clear from your message if it's only
path\to\directory\<spaces>any other characters
path\to\directory\any other characters<spaces>
path\to\directory\<spaces>any other characters\another pathname
path\to\directory\any other characters<spaces>\another pathname
See ? Many such variations. I'm hoping you can narrow this down for me to save
me a lot of time.
I did some more testing, and it can be summed up as I did in the previous comment.
"Filenames and directories that end in spaces"
While explorer can browse to directories with trailing spaces, and even copy
files from within them (though the window will suspiciously dissapear
instantly), it cannot copy the directory itself.
Sorry for the ambiguity and confusion.
I'm seeing this problem as well, which can easily be tested (assuming you have
access to a windows box).
1. Create a file on the share with a trailing space. e.g. 'echo hello > test\ '
2. On my XP box, copying the file from the share to the local filesystem
results in the message 'Cannot copy file: Cannot read from the source file or
I was wonder if it would be more appropriate to change the summary to something
like "Windows clients cannot copy filenames with trailing spaces." or similar.
(In reply to comment #6)
> I was wonder if it would be more appropriate to change the summary to something
> like "Windows clients cannot copy filenames with trailing spaces." or similar.
It would be. I made the discovery that it includes ALL Trailing spaces later.
"Do not end a file or directory name with a trailing space or a period. Although
the underlying file system may support such names, the operating system does not."
Jeremy, do you want to mark this on as WONTFIX ? Or try to
mangle the filename ?
Probably add this as a mangle condition - check the last character (coping with
mb characters of course :-) is a space and always mangle if so. Target for 3.0.21.
Created attachment 1462 [details]
This is the patch for 3.0.21. It also fixes an old bug in mangle_hash method
where we weren't mangling filename with multiple dots that end in a dot.
Fixed in SVN for SAMBA_3_0 and HEAD. Not pulled into 3.0.20a but will be in 3.0.21.
*** Bug 601 has been marked as a duplicate of this bug. ***
*** Bug 1328 has been marked as a duplicate of this bug. ***