UNIX for Dummies Questions & Answers

1.7.11 is newer than 1.7.2. Unless that's a typo of 1.7.1.

Whatever the version, your cygwin does not seem to be able to stat those files. This would explain why ls succeeds but ls -l fails.

The short form ls only reads the contents of the directory. The directory is itself just a file with contents. The directory can be opened because its name is a valid windows name. Reading its contents does not require opening any of those files, so the fact that those contents are strings that represent invalid windows filenames is not relevant. ls is just using basic i/o to print those strings.

However, ls -l passes those strings to the kernel in an attempt to stat those invalid windows filenames. This is necessary to obtain data required by the long listing, such as file size, timestamps, ownership information, permissions, etc.

rm needs to use those filenames to unlink.

I could very well be mistaken, but it fits.

Regards,
Alister

I am updating as I type, just to be sure..I guess it will be a while. Will post back after checking again.

Thanks again guys! You are awesome!

Upon further reflection, since you mentioned that even the windows file manager cannot remove the files, I don't think this is a cygwin issue. I now believe that the unix system used to create these files allowed you to use characters which windows forbids but which ntfs can handle.

Windows does not allow the asterisk at all. When creating a file which contains an asterisk, Cygwin translates it and in its stead writes a utf8 character that looks like a solid dot (which is a valid character as far as windows is concerned). When reading the filename, Cygwin then translates it back to an asterisk for cygwin apps. The windows file manager does not do this and will show you the solid dot.

From what you said about creating the files on unix, I suspect that it wrote a literal asterisk into the filename. The NTFS implementation supports the asterisk, but windows will not accept it when it reads it. And, since ultimately cygwin depends on windows, it fails as well.

If this is correct, the most expedient solution may be to mount that filesystem with the unix system that created it and rename those files.

Regards,
Alister

You may not have used Linux ntfs-3g, but perhaps your driver has similar functionality (to prevent future headaches):
It seems whatever you used employed the POSIX namespace but your Windows machine insists on using the Win32 namespace.

For the record, I have no clue about how these namespaces are utilized or if Windows' notion of which namespace to use when mounting a partition can be overridden.

Please do report back when you sort it out. Your solution may help someone in the future.

Regards,
Alister

---------- Post updated at 12:47 PM ---------- Previous update was at 12:45 PM ----------

In post #15, the OP states that the files were created on a unix system.

Regards,
Alister

I wonder if doing a Windows filesystem integrity check would "fix" the file names? Whatever is the Microsoft equivalent of fsck... is it chkdsk.exe?

Else, yeah, I think a Linux boot CD is your only option, one that has the ntfs-3g module so you can access this ntfs filesystem.

Out of curiosity, why did you create file names with the '*' character in the name? Was it intentional (i.e. there is some legitimate reason to do so), or was this an accidental mistake?

I missed that, sorry!

Yeah, agreed, rescue disk time.

This post implies that it will, but the resulting filenames may not bear any resemblance to the originals: ntfs-3g-devel mailing list: Windows chkdsk and invalid filenames

Regards,
Alister