Not sure. I'd expect the "foo\bar" created on that NTFS volume while mounfed from Linux to be effectively unreachable when accessed from windows (at least while the command line?).
Or not. Surprise me.
You can create file names containing special characters from ntfs-3g that make it nearly impossible to access or remove from within Windows (such as those containing a "?" character). I'm sure there's a way, but neither the command prompt nor Windows Explorer know what to do. Opening such files from a variety of test applications seems to fail as well.
According to the ntfs-3g FAQ, this is expected behavior[1] and is a consequence of NTFS' namespace implementation. Allegedly, such files could be removed via a Samba client, but I've never tried.
I confess that outside mounting the disk under Linux, I know of no first party solution to remove or rename such files; but, I'm also not especially knowledgeable on Windows internals.
There used to be a bug in the GatorBox Mac Localtalk-to-Ethernet NFS bridge that could somehow trick Unix into putting slashes into file names via NFS, which appeared to work fine, but then down the line Unix "restore" would totally shit itself.
That was because Macs at the time (1991 or so) allowed you to use slashes (and spaces of course, but not colons, which it used a a path separator), and of course those silly Mac people, being touchy feely humans instead of hard core nerds, would dare to name files with dates like "My Spreadsheet 01/02/1991".
UFS allows any character in a filename except for the slash (/) and the
ASCII NUL character. (Some versions of Unix allow ASCII characters
with the high-bit, bit 8, set. Others don't.)
This feature is great — especially in versions of Unix based on Berkeley's
Fast File System, which allows filenames longer than 14 characters. It
means that you are free to construct informative, easy-to-understand filenames like these:
1992 Sales Report
Personnel File: Verne, Jules
rt005mfkbgkw0 . cp
Unfortunately, the rest of Unix isn't as tolerant. Of the filenames shown
above, only rt005mfkbgkw0.cp will work with the majority of Unix utili-
ties (which generally can't tolerate spaces in filenames).
However, don't fret: Unix will let you construct filenames that have control
characters or graphics symbols in them. (Some versions will even let you
build files that have no name at all.) This can be a great security feature —
especially if you have control keys on your keyboard that other people
don't have on theirs. That's right: you can literally create files with names
that other people can't access. It sort of makes up for the lack of serious
security access controls in the rest of Unix.
Recall that Unix does place one hard-and-fast restriction on filenames: they
may never, ever contain the magic slash character (/), since the Unix kernel
uses the slash to denote subdirectories. To enforce this requirement, the
Unix kernel simply will never let you create a filename that has a slash in
it. (However, you can have a filename with the 0200 bit set, which does list
on some versions of Unix as a slash character.)
Never? Well, hardly ever.
Date: Mon, 8 Jan 90 18:41:57 PST
From: sun!wrs!yuba!steve@decwrl.dec.com (Steve Sekiguchi)
Subject: Info-Mac Digest V8 #3 5
I've got a rather difficult problem here. We've got a Gator Box run-
ning the NFS/AFP conversion. We use this to hook up Macs and
Suns. With the Sun as a AppleShare File server. All of this works
great!
Now here is the problem, Macs are allowed to create files on the Sun/
Unix fileserver with a "/" in the filename. This is great until you try
to restore one of these files from your "dump" tapes, "restore" core
dumps when it runs into a file with a "/" in the filename. As far as I
can tell the "dump" tape is fine.
Does anyone have a suggestion for getting the files off the backup
tape?
Thanks in Advance,
Steven Sekiguchi Wind River Systems
sun!wrs!steve, steve@wrs.com Emeryville CA, 94608
Apparently Sun's circa 1990 NFS server (which runs inside the kernel)
assumed that an NFS client would never, ever send a filename that had a
slash inside it and thus didn't bother to check for the illegal character.
We're surprised that the files got written to the dump tape at all. (Then
again, perhaps they didn't. There's really no way to tell for sure, is there
now?)
I'd forgotten about Cygwin! Next time I think about it, that might be capable of removing said files as well (although, I guess that qualifies as a 3rd party tool).
I have it installed on my Windows machine. I ought to give it a try.
I think the intention was that 'foo/bar' and 'foo' would be in the same directory, therefore when typing C:\foo/bar into the file explorer you would have an ambiguous path. Perhaps I misunderstood.
