Cannot remove file from NTFS file system

Did you use -F in your ls command? Otherwise the asterisk is part of the file name. I would use ls -A -b -l which will show any non-printing characters that may be in the file names (you must have used -A or -a to see these files with names starting period). Absent non-printing characters, try

rm '.Archive(1)_2011_04_18_21_00_03_166D17.TIB.jO3zF0*'

Select allOpen in new window

Using single quotes obviates the need to escape the parentheses. But you will need to use escapes if there are non-printing characters in the file names.

Nope, still not working. When I do your suggested 'ls' I get:

$ /usr/bin/ls -A -b -l
total 516867812
-rwxrwxrwx 1 ohprs ohprs   8442151424 May  7  2011 .Archive(1)_2011_04_18_21_00_03_166D17.TIB.jO3zF0
-rwxrwxrwx 1 ohprs ohprs   1142719488 Mar 28  2012 .Archive(1)_2012_03_23_20_00_04_167D4.TIB.Fze0DB

Select allOpen in new window

No non-printing characters, and no * on the filename (the ls command is normally aliases to have -F) Likewise the rm:

$ rm '.Archive\(1\)_2011_04_18_21_00_03_166D17.TIB.jO3zF0*'
rm: cannot remove `.Archive\\(1\\)_2011_04_18_21_00_03_166D17.TIB.jO3zF0*': No such file or directory

I'm using tab-name-completion anyway when typing in the name, so that should escape the funny characters -- as it does for the parenthesis.

I think I have some kind if filesystem issue. Is there anyway to force the removal of these files without reformatting the whole drive?

Try copy and paste the entire filename inside the single quotes -

rm '.Archive(1)_2011_04_18_21_00_03_166D17.TIB.jO3zF0*'

Select allOpen in new window

Not the following, I do not see slashes in your list command?

rm '.Archive[b]\[/b](1[b]\[/b])_2011_04_18_21_00_03_166D17.TIB.jO3zF0*'

Select allOpen in new window

I meant for you not to put '*' in the rm command if you knew it was not part of the file name. I guess you tried that anyway?
Name completion should be good - maybe you do have a problem. NTFS file names are stored in Unicode. The filesystem is supposed to translate these to Ascii. Maybe the underscores are long dashes or something like that.
You could try wildcards. Use rm -i so you can verify that you really want to delete. E.g. rm -i .Archive*2011*04*18*21*00*03*166D17.TIB.jO3zF0, or even rm -i .Archive*2011*04*18*21*00*03*

I've tried various permutations of name and wildcards. Lastly, I've created a new folder, moved the good files into the new folder leaving only the funky files. Then tried

rm -r MAIL
rm: cannot remove `MAIL/.Archive(1)_2011_04_18_21_00_03_166D17.TIB.jO3zF0': No such file or directory
rm: cannot remove `MAIL/.Archive(1)_2012_03_23_20_00_04_167D4.TIB.Fze0DB': No such file or directory

Select allOpen in new window

I then tried moving the folder to another filesystem:

mv MAIL ~

and that just hung.

I've been looking at the ntfsprogs suite. Some of this utilities appear to give diagnositics or do some kinds of repair. Do you (or anyone) know anything about this? I don't want to have to reformat this drive and copy 1TB of data back to it across the network!

It seems that Windows chkdsk is the answer; even being the recommended solution on Linux sites: http://askubuntu.com/questions/58755/repair-whole-ntfs-filesystem

I plugged the drive into an XP system and ran chkdsk (at the cmd level, the My Computer > [drive] > Properties > Tools > Error Checking, tool hung). It quickly found and fixed the allocation problems and I was able to delete the bogus files, in XP!

duncan_roe: > Personally I always re-format terabyte drives to ext3 before using them.

So do I, but this drive is the remote of a pair of mirror drives storing SQL Server database backups and Acronis images for Windows and are intended to be plugged into Windows computers for recovery. Thus, they need to be read directly by Windows computers at recovery time. Linux is doing the mirror synchronization rather than windows because it has superior tools like cron, bash and rsync. I don't even know how I'd do a remote synchronization on Windows, in fact.

One last little thing before I close this out. When I rsync'd the newly chkdsk'd drive early this morning the rsync program deleted the files:

System Volume Information/_restore{6DC7788F-4A81-4012-AB7C-C32254422C9C}/RP251/change.log
deleting System Volume Information/_restore{6DC7788F-4A81-4012-AB7C-C32254422C9C}/RP251/
System Volume Information/_restore{6DC7788F-4A81-4012-AB7C-C32254422C9C}/
System Volume Information/tracking.log
System Volume Information/MountPointManagerRemoteDatabase
System Volume Information/

These files were obviously re-created by chkdsk, but are missing from the source NTFS drive. Should I reconstruct these again and exclude them from the rsync process, or are the not terribly important to worry about?

If it were me, I wouldn't worry about them.  I would guess it was some kind of restore point. But I'm only an XP user.

The directory is for NTFS - system restores and indexing...etc. You can safely ignore it on the Linux side.

Mazdajai, thanks for the response. The thing is, this drive is for emergency restoration to Windows, so if it does get used for its intended task it will be on a Windows system. If I do need to use it on a Windows computer, should I first run chkdsk?

You only need to run chkdsk if there is corrupted file system error (event id 55) in Windows event log.

Running chkdsk is optional. Note that on a large drive chkdsk may take a while. I have seen it can take up to 12 hours because it need to read and analyze the entire file systems.

For emergency, I would do the restore first and run chkdsk only if needed.

Thanks for the help. I've put the "System Volume Information" folder into the --exclude option for rsync, so that should solve the final issue.