strange ntfs filename restriction (by design?)

[PiErre]

Hi,
I never read before of this strange behaviour of ntfs so I decided
to ask
the ng for help ;-P
I can create a file with extension ".." (i.e.: "foo...") only from a
linux
machine on a remote ntfs (I tested both a drive of a winXPpro machine
and
one from our old nt4server) drive mounted via "smb". I cannot access,
rename
or remove it neither via explorer.exe (trying to delete it leads to
the error "Error Deleting
File or Folder - Cannot delete file: Cannot read from the source file
or disk.")
nor from within a cmd shell (with the correspond message "Could Not
Find C:\Documents and Settings\gallivm\Desktop\foo...").
BTW: if you try to create a file with such a name directly in windows
it results in a
file without extension... (the same even with a "copy con foo..." from
within a cmd
shell) funny, isn't it?
Luckily from a cmd you can delete it with "del foo*" or using the
short-name but
not with "del foo???"...
My problem was that I was trying to write a .bat script for daily
copying a directory tree
and it break during the process (I found the offendig file was
"C:\Languages\Python\Python 2.2\Python-2.2.3\Mac\IDE scripts\Hold
option to open a script..."
probably from a python package).
Any suggestion?
TIA
bye,
PiErre

 

[Rob Schneider]

Clearly there is rule in the file system which prevents use of so many
full stops (.). Probably by design else it would work. And yes, this
type of filename is accepted in EXT3 file system in Linux which is why
you probably could recreate it even on a remote NTFS device.

Does it really matter?

If you are trying to do a daily copy of a directory tree, why not use
the copy command, or xcopy command, or even better: use robocopy
available free from Microsoft download site. Why re-create all this in
Python?

Or you could maybe do your daily copy from the remote Linux machine ...

You could also consider removing what looks to be a Mac file from the XP
box ..

May wish to re-ask you question in a Newsgroup for Python as they may
know about this particular file, why it's installed on XP verson of
Python, and how to deal with it.

Hope this is useful to you. Let us know.

rms

 

[Alex Nichol]

Clearly there is rule in the file system which prevents use of so many
full stops (.). Probably by design else it would work.

a period (.) is considered in windows file systems as a separator
between fields, and you are not allowed a null field in between. There
are some other characters that have restricted special use - or are
totally prohibited, too

 

[Tim Slattery]

a period (.) is considered in windows file systems as a separator
between fields, and you are not allowed a null field in between. There
are some other characters that have restricted special use - or are
totally prohibited, too

I don't think so. I just saved a file named "odd..filename.txt" on my
WinXP Pro system. It's sitting there on my disk, I can double-click it
and it opens in the associated program, just like it should.

The directory structure in DOS allowed eleven characters for a file
name. That was separated into two fields, one eight bytes and one
three bytes. DOS expected a file name to have a root part and an
extension, separated by a dot. More than one dot in a file name was
not allowed.

NTFS certainly doesn't care about extra dots (as my experiment
proves). I don't have Win9x system here to experiment on, but I think
it would handle also. It would create a DOS-style 8.3 name (as it does
for all file names that don't fit the 8.3 spec), and would store both
that name and the full name.