By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,454 Members | 1,804 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,454 IT Pros & Developers. It's quick & easy.

spaces at ends of filenames or directory names on Win32

P: n/a
# Spaces are present before and after the XXX
filename = ' XXX '

new_filename = filename.strip()

if new_filename != filename:
print filename

Macs allow these spaces in file and folder names. Which is OK. The
problem arises when the file or folder is copied to a PC running Windows
from a Mac. Windows allows the Mac to copy the file to it, but when
Windows itself attempts to do anything with the file it strips the
spaces and then tries to move it, copy it, etc and complains that the
file isn't there!

I can rectify this by striping the spaces from the files and folders on
the Mac before they are copied to the PC or mounting the Windows share
from the Mac and running a recursive strip program I wrote, but Windows
will not allow the whitespace removal directly from within Windows....
how annoying!

For example... tell windows to move a file named ' XXX ' (one space
before and one space after the filename). Windows will complain that
file 'XXX' does not exist. It's correct of course, 'XXX' does not exist,
but ' XXX ' does indeed exist.

Can anyone rescue me from this madness :(

Many Thanks,
Brad
Feb 23 '06 #1
Share this Question
Share on Google+
22 Replies


P: n/a
rtilley wrote:
# Spaces are present before and after the XXX
filename = ' XXX '

new_filename = filename.strip()

if new_filename != filename:
print filename

Macs allow these spaces in file and folder names. Which is OK. The
problem arises when the file or folder is copied to a PC running Windows
from a Mac. Windows allows the Mac to copy the file to it, but when
Windows itself attempts to do anything with the file it strips the
spaces and then tries to move it, copy it, etc and complains that the
file isn't there!

I can rectify this by striping the spaces from the files and folders on
the Mac before they are copied to the PC or mounting the Windows share
from the Mac and running a recursive strip program I wrote, but Windows
will not allow the whitespace removal directly from within Windows....
how annoying!

For example... tell windows to move a file named ' XXX ' (one space
before and one space after the filename). Windows will complain that
file 'XXX' does not exist. It's correct of course, 'XXX' does not exist,
but ' XXX ' does indeed exist.

Can anyone rescue me from this madness :(

Many Thanks,
Brad


How about not naming files with leading and trailing spaces on
the Mac? Seems like a bad habit that needs breaking ;-).

-Larry Bates
Feb 23 '06 #2

P: n/a
Larry Bates wrote:
How about not naming files with leading and trailing spaces on
the Mac? Seems like a bad habit that needs breaking ;-).

-Larry Bates


Users will be users! Tell that to the guys and gals on Macs who like to
make a folder sort based on the number of spaces they've placed in the
front of the filenames :)
Feb 23 '06 #3

P: n/a
rtilley wrote:
Larry Bates wrote:
How about not naming files with leading and trailing spaces on
the Mac? Seems like a bad habit that needs breaking ;-).

-Larry Bates


Users will be users! Tell that to the guys and gals on Macs who like to
make a folder sort based on the number of spaces they've placed in the
front of the filenames :)


Sounds like you should change leading/trailing spaces to something
like underlines instead of stripping them off the filename. That way
you preserve the character positions, visually the filenames are very
close. Problem is that underlines sort to bottom instead of to the
top of a list of files.

On second thought, if you replace spaces with dashes they will sort
correctly, but they will look odd.

Pick your poison.

-Larry
Feb 23 '06 #4

P: n/a
rtilley wrote:
# Spaces are present before and after the XXX
filename = ' XXX '

new_filename = filename.strip()

if new_filename != filename:
print filename

Macs allow these spaces in file and folder names. Which is OK. The
problem arises when the file or folder is copied to a PC running Windows
from a Mac. Windows allows the Mac to copy the file to it, but when
Windows itself attempts to do anything with the file it strips the
spaces and then tries to move it, copy it, etc and complains that the
file isn't there!

I can rectify this by striping the spaces from the files and folders on
the Mac before they are copied to the PC or mounting the Windows share
from the Mac and running a recursive strip program I wrote, but Windows
will not allow the whitespace removal directly from within Windows....
how annoying!

For example... tell windows to move a file named ' XXX ' (one space
before and one space after the filename). Windows will complain that
file 'XXX' does not exist. It's correct of course, 'XXX' does not exist,
but ' XXX ' does indeed exist.

Can anyone rescue me from this madness :(
Use quatation marks.
copy tt1.txt " XXX " 1 file(s) copied.
dir XXX Volume in drive C is XXXXPXXABA
Volume Serial Number is 90C0-740E

Directory of C:\Documents and Settings\Desktop

File Not Found
dir " XXX Volume in drive C is XXXXPXXABA
Volume Serial Number is 90C0-740E

Directory of C:\Documents and Settings\Desktop

02/06/2006 07:05p 10 XXX
1 File(s) 10 bytes
0 Dir(s) 2,063,822,848 bytes free
dir *. Volume in drive C is XXXXPXXABA
Volume Serial Number is 90C0-740E

Directory of C:\Documents and Settings\Desktop

02/23/2006 03:20p <DIR> .
02/23/2006 03:20p <DIR> ..
02/06/2006 07:05p 10 XXX
01/20/2006 04:53p <DIR> AGMP
01/20/2006 04:53p <DIR> BPWR Fe-Mn
01/20/2006 04:53p <DIR> GM
01/20/2006 04:53p <DIR> IDEM response
01/20/2006 04:53p <DIR> msgs
01/20/2006 04:53p <DIR> New Folder
02/08/2006 05:29p <DIR> New Folder (2)
01/20/2006 04:53p <DIR> OCAML
01/20/2006 04:53p <DIR> review05
01/20/2006 04:53p <DIR> scanned docs
02/17/2006 03:07p <DIR> USS repository
1 File(s) 10 bytes
13 Dir(s) 2,063,822,848 bytes free

Note that the trailing quote isn't always necessary.
Note from the last listing that the XXX file is indented one space.

Many Thanks,
Brad


Feb 23 '06 #5

P: n/a
On Thu, 23 Feb 2006 14:30:22 -0600, Larry Bates wrote:
How about not naming files with leading and trailing spaces on
the Mac? Seems like a bad habit that needs breaking ;-).


Why is it a bad habit? Because *Windows* is primitive enough that it can't
cope with leading and trailing spaces? I don't see why Windows' lack is
Mac users' problem.
--
Steven.

Feb 23 '06 #6

P: n/a

Steven D'Aprano wrote:
On Thu, 23 Feb 2006 14:30:22 -0600, Larry Bates wrote:
How about not naming files with leading and trailing spaces on
the Mac? Seems like a bad habit that needs breaking ;-).


Why is it a bad habit? Because *Windows* is primitive enough that it can't
cope with leading and trailing spaces? I don't see why Windows' lack is
Mac users' problem.

It is a problem because the poster says it is a problem for him.
If they want to leave the files on a Mac, there is no problem.

IMHO leading and/or trailing spaces in filenames is asking for
incompatibilities with cross-platform file access. Much like
using single-quote in filenames which are perfectly legal in
DOS/Windows, but Linux doesn't like much.

-Larry Bates
Feb 24 '06 #7

P: n/a
Larry Bates wrote:
IMHO leading and/or trailing spaces in filenames is asking for
incompatibilities with cross-platform file access.
With what platforms specifically?
Much like
using single-quote in filenames which are perfectly legal in
DOS/Windows, but Linux doesn't like much.


Uh... What Linux are you using? And what FS?

$ touch "'" && ls
'
$ rm "'"
$
Feb 24 '06 #8

P: n/a
On Thu, 23 Feb 2006 17:49:31 -0600, Larry Bates wrote:
Steven D'Aprano wrote:
On Thu, 23 Feb 2006 14:30:22 -0600, Larry Bates wrote:
How about not naming files with leading and trailing spaces on
the Mac? Seems like a bad habit that needs breaking ;-).


Why is it a bad habit? Because *Windows* is primitive enough that it can't
cope with leading and trailing spaces? I don't see why Windows' lack is
Mac users' problem.

It is a problem because the poster says it is a problem for him.


Absolutely.

Now read my statement again. Why is it a problem for the Mac _users_?

I use Linux, Windows and Mac, in varying amounts. I'm fully aware of the
problems of transferring files from one platform to another. When it
affects _me_, I may choose to dumb down to the lowest common denominator
so as to save _me_ problems. But wearing my user hat, if a developer came
to me telling me I had to avoid using features on my platform of choice in
order to make his life easier, I'd say to him "So why exactly are we
paying you the big bucks? That's your problem, you solve it."

--
Steven.

Feb 24 '06 #9

P: n/a
rtilley <rt*****@vt.edu> wrote:

For example... tell windows to move a file named ' XXX ' (one space
before and one space after the filename). Windows will complain that
file 'XXX' does not exist. It's correct of course, 'XXX' does not exist,
but ' XXX ' does indeed exist.


Are you sure you're doing it right? It works for me. Notice that I have
"x.c" and " x.c " in the same directory at the same time.

C:\tmp\x>copy ..\x.c .
1 file(s) copied.

C:\tmp\x>dir
Volume in drive C has no label.
Volume Serial Number is 70CF-E8F4

Directory of C:\tmp\x

02/24/2006 11:48 PM <DIR> .
02/24/2006 11:48 PM <DIR> ..
02/22/2006 10:49 PM 539 x.c
1 File(s) 539 bytes
2 Dir(s) 50,937,999,360 bytes free

C:\tmp\x>copy x.c " x.c "
1 file(s) copied.

C:\tmp\x>dir
Volume in drive C has no label.
Volume Serial Number is 70CF-E8F4

Directory of C:\tmp\x

02/24/2006 11:48 PM <DIR> .
02/24/2006 11:48 PM <DIR> ..
02/22/2006 10:49 PM 539 x.c
02/22/2006 10:49 PM 539 x.c
2 File(s) 1,078 bytes
2 Dir(s) 50,937,999,360 bytes free

C:\tmp\x>erase " x.c "

C:\tmp\x>dir
Volume in drive C has no label.
Volume Serial Number is 70CF-E8F4

Directory of C:\tmp\x

02/24/2006 11:49 PM <DIR> .
02/24/2006 11:49 PM <DIR> ..
02/22/2006 10:49 PM 539 x.c
1 File(s) 539 bytes
2 Dir(s) 50,937,999,360 bytes free

C:\tmp\x>
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Feb 25 '06 #10

P: n/a
For example... tell windows to move a file named ' XXX ' (one space
before and one space after the filename). Windows will complain that
file 'XXX' does not exist. It's correct of course, 'XXX' does not
exist,
but ' XXX ' does indeed exist.

Can anyone rescue me from this madness :(
-----
Please post your Python code. I don't see the problem you're
describing.

Feb 25 '06 #11

P: n/a
Jeffrey Schwab wrote:
Larry Bates wrote:
IMHO leading and/or trailing spaces in filenames is asking for
incompatibilities with cross-platform file access.


With what platforms specifically?
Much like
using single-quote in filenames which are perfectly legal in
DOS/Windows, but Linux doesn't like much.


Uh... What Linux are you using? And what FS?

$ touch "'" && ls
'
$ rm "'"
$


I stand corrected if you put double quotes around filenames
it does work. That to me means that single quotes
in filenames are somehow "different" than other characters.
You must handle these filenames differently (at least from
the command line). Thanks for pointing this out.

-Larry Bates

Feb 25 '06 #12

P: n/a
Steven D'Aprano wrote:
On Thu, 23 Feb 2006 17:49:31 -0600, Larry Bates wrote:
Steven D'Aprano wrote:
On Thu, 23 Feb 2006 14:30:22 -0600, Larry Bates wrote:

How about not naming files with leading and trailing spaces on
the Mac? Seems like a bad habit that needs breaking ;-).
Why is it a bad habit? Because *Windows* is primitive enough that it can't
cope with leading and trailing spaces? I don't see why Windows' lack is
Mac users' problem.

It is a problem because the poster says it is a problem for him.


Absolutely.

Now read my statement again. Why is it a problem for the Mac _users_?

I use Linux, Windows and Mac, in varying amounts. I'm fully aware of the
problems of transferring files from one platform to another. When it
affects _me_, I may choose to dumb down to the lowest common denominator
so as to save _me_ problems. But wearing my user hat, if a developer came
to me telling me I had to avoid using features on my platform of choice in
order to make his life easier, I'd say to him "So why exactly are we
paying you the big bucks? That's your problem, you solve it."

I understand you completely, but its a problem for the Mac users because
their company needs to do something with their files that is making it
hard. I see no difference than if some user chose to use some obscure
spreadsheet or wordprocessing program that works extremely well for them
but is completely incompatible with all other users in the organization.
Why is it their problem? Because it makes it difficult for others to
work with their data. I don't believe for a minute you would tell them
"It is ok to keep using your wordprocessing software, if we can't read
the files that's our problem, we will write something to convert them
to a more usable format. It will only take about 500/1000/2000 hours
to fix for you Mr. _user_."

Funny how we got here. I just made a suggestion as to how the user can
make the problem go away altogether and my suggestion that it was a bad
habit did have a smiley ;-) as you will note.

-Larry Bates
Feb 25 '06 #13

P: n/a
Larry Bates wrote:
Jeffrey Schwab wrote:
Larry Bates wrote:

IMHO leading and/or trailing spaces in filenames is asking for
incompatibilities with cross-platform file access.


With what platforms specifically?

Much like
using single-quote in filenames which are perfectly legal in
DOS/Windows, but Linux doesn't like much.


Uh... What Linux are you using? And what FS?

$ touch "'" && ls
'
$ rm "'"
$

I stand corrected if you put double quotes around filenames
it does work. That to me means that single quotes
in filenames are somehow "different" than other characters.
You must handle these filenames differently (at least from
the command line). Thanks for pointing this out.


Sure, no problem. FYI, the quotes are to keep my shell, which happens
to be bash, from trying to interpret the quote. If I were renaming a
file by clicking the icon in a Windows-like GUI, or using a file
manager, there would be no need for the quote.
Feb 26 '06 #14

P: n/a
dr******@gmail.com wrote:
For example... tell windows to move a file named ' XXX ' (one space
before and one space after the filename). Windows will complain that
file 'XXX' does not exist. It's correct of course, 'XXX' does not
exist,
but ' XXX ' does indeed exist.

Can anyone rescue me from this madness :(


Use double-quotes on Windows, not single-quotes. Single-quotes are taken
as just another filename character.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Feb 27 '06 #15

P: n/a
dr******@gmail.com wrote:
Please post your Python code. I don't see the problem you're
describing.


OK, here's a copy. This works on Mac/Unix/Linux yet has no effect on
Windows:

-----------------------------------------------------------------
import os
import os.path

for root, dirs, files in os.walk(os.getcwd()):
for d in dirs:
new_d = d.strip()

## Uncomment the next 4 lines just to print dirs with end spaces.
## if new_d != d:
## print d
## else:
## print "No end spaces."

## Uncomment the next 7 lines to try a rename of dirs with end spaces.
## if new_d != d:
## try:
## new_path = os.path.join(root, new_d)
## old_path = os.path.join(root, d)
## os.renames(old_path, new_path)
## except Exception, e:
## print e
------------------------------------------------------------------
Feb 27 '06 #16

P: n/a
dr******@gmail.com wrote:
Please post your Python code. I don't see the problem you're
describing.


OK, here's a copy. This works on Mac/Unix/Linux yet has no effect on
Windows:

-----------------------------------------------------------------
import os
import os.path

for root, dirs, files in os.walk(os.getcwd()):
for d in dirs:
new_d = d.strip()

## Uncomment the next 4 lines just to print dirs with end spaces.
## if new_d != d:
## print d
## else:
## print "No end spaces."

## Uncomment the next 7 lines to try a rename of dirs with end spaces.
## if new_d != d:
## try:
## new_path = os.path.join(root, new_d)
## old_path = os.path.join(root, d)
## os.renames(old_path, new_path)
## except Exception, e:
## print e
------------------------------------------------------------------
Feb 27 '06 #17

P: n/a
This will at least allow me to ID folders that start with whitespace...
from within Windows too :) yet I still cannot rename the folders after
stripping the whitespace... attempting to gives an [Errno 2] No such
file or directory. The strip seems to work right too according to the
prints before and after.

import os
import os.path
import string

dirs = os.listdir(os.getcwd())
path = os.getcwd()
##print path

for d in dirs:
# If the first space in a folder name is whitespace.
if d[0] in string.whitespace:
## print d
try:
new_path = os.path.join(path, d.strip())
old_path = os.path.join(path, d)
print new_path
print old_path
os.renames(old_path, new_path)
except Exception, e:
print e
else:
pass
Feb 27 '06 #18

P: n/a
rtilley schreef:
This will at least allow me to ID folders that start with whitespace...
from within Windows too :) yet I still cannot rename the folders after
stripping the whitespace... attempting to gives an [Errno 2] No such
file or directory. The strip seems to work right too according to the
prints before and after.


Does the rename work if try with other names? Maybe the problem is not
the whitespace; maybe Windows can't rename the folder because some
process, possibly your program, has an open handle to a file or
directory under your folder? Unix-systems are able to handle that
easily, but Windows doesn't.

--
If I have been able to see further, it was only because I stood
on the shoulders of giants. -- Isaac Newton

Roel Schroeven
Feb 27 '06 #19

P: n/a
Roel Schroeven wrote:
rtilley schreef:
This will at least allow me to ID folders that start with
whitespace... from within Windows too :) yet I still cannot rename the
folders after stripping the whitespace... attempting to gives an
[Errno 2] No such file or directory. The strip seems to work right too
according to the prints before and after.

Does the rename work if try with other names?


Yes, the script can rename files that have no end whitespace. Also, I
should note the the Windows GUI cannot rename the files. Same error...
cannot stat the file. The only way I've been able to rename is through
the cmd prompt using quotes like this:

ren " bad file with end spaces " good_file_no_end_spaces

I should also note that the code I posted earlier is misleading as
os.listdir() gets dirs and files... not just dirs as I implied. Here's a
better example that should get whitespace at either end (and does indeed
on Mac and Unix... but not Windows)

--------------------------------------------------------

import os
import os.path
import string

# dirs is actually files and folders, not just folders.
dirs = os.listdir(os.getcwd())
path = os.getcwd()
print path

for d in dirs:

# If folder name begins with whitespace.
if d[0] in string.whitespace:
print d
try:
new_path = os.path.join(path, d.strip())
old_path = os.path.join(path, d)
print new_path
print old_path
os.renames(old_path, new_path)
except Exception, e:
print e

# If folder name ends with whitespace.
elif d[-1] in string.whitespace:
print d
try:
new_path = os.path.join(path, d.strip())
old_path = os.path.join(path, d)
print new_path
print old_path
os.renames(old_path, new_path)
except Exception, e:
print e

# Folder name is OK, so skip it.
else:
pass
Feb 28 '06 #20

P: n/a

rtilley wrote:
Roel Schroeven wrote:
rtilley schreef:
This will at least allow me to ID folders that start with
whitespace... from within Windows too :) yet I still cannot rename the
folders after stripping the whitespace... attempting to gives an
[Errno 2] No such file or directory. The strip seems to work right too
according to the prints before and after.

Does the rename work if try with other names?


Yes, the script can rename files that have no end whitespace. Also, I
should note the the Windows GUI cannot rename the files. Same error...
cannot stat the file. The only way I've been able to rename is through
the cmd prompt using quotes like this:

ren " bad file with end spaces " good_file_no_end_spaces

I should also note that the code I posted earlier is misleading as
os.listdir() gets dirs and files... not just dirs as I implied. Here's a
better example that should get whitespace at either end (and does indeed
on Mac and Unix... but not Windows)


It works for me.

And although you can't put leading spaces in file names using
Windows explorer, you don't have to use command line rename.

I modified your program to also put leading spaces back in.

It works fine also. See sample run at end of code.
<original code snipped>
<replaced with my version>

import os
import os.path
import string

# dirs is actually files and folders, not just folders.
dirs = os.listdir(os.getcwd())
path = os.getcwd()
print path

for d in dirs:
# If folder name begins with whitespace.
if d[0] in string.whitespace:
print d
try:
new_path = os.path.join(path, d.strip())
old_path = os.path.join(path, d)
print new_path
print old_path
os.renames(old_path, new_path)
except Exception, e:
print e

# If folder name ends with whitespace.
elif d[-1] in string.whitespace:
print d
try:
new_path = os.path.join(path, d.strip())
old_path = os.path.join(path, d)
print new_path
print old_path
os.renames(old_path, new_path)
except Exception, e:
print e

# Folder name is OK, so put spaces back in.
else:
if d[0] in '123':
try:
new_path = os.path.join(path, ' '*int(d[0])+d)
old_path = os.path.join(path, d)
print new_path
print old_path
os.renames(old_path, new_path)
except Exception, e:
print e

"""

D:\wstest>dir
Volume in drive D is VOL_LOG1
Volume Serial Number is CCB3-C62B

Directory of D:\wstest

02/27/2006 07:38p <DIR> .
02/27/2006 07:38p <DIR> ..
02/27/2006 07:03p 1,052 3
02/27/2006 07:03p 1,052 2
02/27/2006 07:03p 1,052 1
02/27/2006 07:37p 1,344 wstest.py
4 File(s) 4,500 bytes
2 Dir(s) 1,007,540,736 bytes free

D:\wstest>C:\Python24\python.exe wstest.py
D:\wstest
3
D:\wstest\3
D:\wstest\ 3
2
D:\wstest\2
D:\wstest\ 2
1
D:\wstest\1
D:\wstest\ 1

D:\wstest>dir
Volume in drive D is VOL_LOG1
Volume Serial Number is CCB3-C62B

Directory of D:\wstest

02/27/2006 07:38p <DIR> .
02/27/2006 07:38p <DIR> ..
02/27/2006 07:03p 1,052 1
02/27/2006 07:03p 1,052 2
02/27/2006 07:03p 1,052 3
02/27/2006 07:37p 1,344 wstest.py
4 File(s) 4,500 bytes
2 Dir(s) 1,007,540,736 bytes free

D:\wstest>C:\Python24\python.exe wstest.py
D:\wstest
D:\wstest\ 1
D:\wstest\1
D:\wstest\ 2
D:\wstest\2
D:\wstest\ 3
D:\wstest\3

D:\wstest>dir
Volume in drive D is VOL_LOG1
Volume Serial Number is CCB3-C62B

Directory of D:\wstest

02/27/2006 07:40p <DIR> .
02/27/2006 07:40p <DIR> ..
02/27/2006 07:03p 1,052 3
02/27/2006 07:03p 1,052 2
02/27/2006 07:03p 1,052 1
02/27/2006 07:37p 1,344 wstest.py
4 File(s) 4,500 bytes
2 Dir(s) 1,007,540,736 bytes free

"""

Feb 28 '06 #21

P: n/a
me********@aol.com wrote:
It works for me.


Right. I've found that it's not just the end spaces. The Macs somehow
copy these files and folders to the PCs without a security descriptor of
any type! When I goto the folder's properties, I see three tabs:

1. General
2. Web Sharing
3. Customize

They lack the 'Sharing' and 'Security' tabs. The filesystem is NTFS.
This explains a lot, but I'm still at a loss on how to fix it. It's also
getting too off-topic for this list, so I'll leave you guys alone. I'll
work it out somehow.

Many Thanks for all the tips,
Brad

Feb 28 '06 #22

P: n/a
On Thu, 23 Feb 2006 17:49:31 -0600, rumours say that Larry Bates
<la*********@websafe.com> might have written:
IMHO leading and/or trailing spaces in filenames is asking for
incompatibilities with cross-platform file access. Much like
using single-quote in filenames which are perfectly legal in
DOS/Windows, but Linux doesn't like much.


Just for those who don't know, in general *nix operating systems (and the
various *nix file systems) disallow only '\0' and '/' in filenames. The '/'
because obviously is the path separator, and '\0' because it's the
end-of-string marker in C.

When Larry said "Linux", he actually meant the shell he uses.
--
TZOTZIOY, I speak England very best.
"Dear Paul,
please stop spamming us."
The Corinthians
Mar 2 '06 #23

This discussion thread is closed

Replies have been disabled for this discussion.