Interoperability issue: Undocumented flag on NTFS directories allows or disallows translation of directory name and files within it

[Jonas Olsson]

On Tue, 3 Aug 2004, Christopher R. Hertel wrote:

> > We thought we checked all
> > available file attributes but somehow we managed to overlook the read-only
> > flag that was set on all directories where translation worked.
> >
> > A few lines of script later and I was able to verify that it was indeed
> > the read-only flag on the directory that controls whether or not the
> > directory and its contents are translated by desktop.ini entries.
>
> Also check the System flag.  I've seen some instances in which read-only
> was *not* set but system was, and in those cases desktop.ini was
> processed.  I could be wrong, so your feedback would be of interest.

You are quite correct. The system flag also signals processing of
the desktop.ini file to XP.

> > The reason that xcopy didn't produce translating directories is of course
> > that it doesn't preserve the read-only flags on directories. Neither does
> > a Samba share.
>
> Interesting stuff.  This is one of those unix-to-windows semantics
> translation problems.  Given normal Unix semantics, I don't know of a
> clean way to mimic the behavior outside of making use of extended
> filesystem features.

Yes, for obvious reasons the current "map system" implementation does not
set the system flag on directories. However, wouldn't an effective
workaround be to make a per-share directive telling Samba to present all
directories to clients with the read-only or system flag set?

Since it seems that neither the system nor the read-only flag has any
effect on programs or the OS other than enabling processing of the
desktop.ini file (not sure about interoperability with older clients) this
should work out nicely if you have need of dynamically translated
filenames and directories on a Samba share, for example if you wish to
relocate a central start menu to your Samba domain server.

Using desktop.ini to translate filenames can have rather interesting
consequences. Try the following from Windows Explorer in XP:

1. Make a copy of a translated directory and put it in the same parent
   directory as the original.

2. You will notice that you now have two directories with the same
   name in the same directory.

3. Try renaming one of the directories. Ok, that seems to work. Now
   refresh your view in Explorer. Huh, both directories changed name?
   If you have a look at the real filesystem you'll also notice that
   neither of the directories' real names changed.

The explanation for this is that Explorer saves translations of files
and directories in a registry key when you rename translated items
from the GUI.

Look for these static translation values in
HKCU\Software\Microsoft\Windows\Shell\LocalizedResourceName

It is also worth noting that Explorer caches translations under
another key:

HKCU\Software\Microsoft\Windows\ShellNoRoam\MUICache

When troubleshooting why translation does not work as intended these
two registry keys should be checked out first.

  /Jonas Olsson