Moritz Bechler wrote: > Hi, > > I know this has come up some time before on this list but as we are working > on a OpenAFS setup including windows and linux clients and we ran into > problems having folder redirections on windows pointing to our AFS because > of the clients inability to store extended/dos attributes, I want to bring > it up once again. > This is especially annoying for desktop.ini files and recycler directories > and really might confuse our users so we are willing to do something about > it. As maintaining a "hacked" version is really not what we want we are > looking for a solution that can make it into the mainline releases. > > The roadmap of OpenAFS for Windows tells about this extended/dos attribute > thing and mentions it in combination with alternate data streams for windows. > I don't think this is a cross-platform compatible approach, is it?
This is the cross-platform compatible approach. Multiple data streams is the mechanism that is used by Microsoft Windows to store meta-data associated with files. It is also the mechanism by MacOS X to store meta-data. The meta-data that Windows stores is not just the Hidden and System attributes from DOS FAT but also a variety of other data including the source of data downloaded and stored using Internet Explorer, search tags, etc. Implementing multiple data streams requires changes on the file server and extensions to the AFS3 wire protocol. We have designed the architecture but we do not have the resources to implement it. > We thought of several possibilities of implementing this: > > - Implement a windows-only client side ignore list, somehow like samba does > with its "hide files"-directive, simply setting the hidden attribute on > files matching a given pattern - this does not really fix the problem, > but lessen it a bit. This doesn't fix the problem and can cause unwanted side-effects. Its not just the Hidden Attribute that is important to the Windows Explorer Shell but the System Attribute as well. Toggling of the attributes on directory entries (not the desktop.ini file) result in special behaviors. It is the marking of the System Attribute on the directory that causes the desktop.ini file to be looked for UNLESS you are in one of the directories that Explorer Shell knows is special. > - Implement attribute storage on the server and get linux/unix/etc. to > implement another possibility (e.g. some extended attribute thing) > for marking files hidden ... quite illusionary I think. > > - Implement some filename transformation mechanism on windows, moving > windows hidden files to dot files with transparent access - has been > discussed and rejected in the past as it might cause trouble. > > - Implement some attribute storage on the server, then map to the hidden > flags on Windows and map to dot files on unix/linux operating systems. > This might include storing dot files created on linux/unix without the > dot but with a hidden flag. The attribute storage that would be implemented on the file server is "multiple data streams" per file name. Then one of the stream names would be reserved. For example "AFS3-DOS-Extended-Attributes" and the actual attributes would be stored under the name filename:AFS3-DOS-Extended-Attributes This would be ignored on UNIX and be looked for by Windows clients that support it. It could be looked for by MacOS X client > The main problem is the totally different approach of unix/linux operating > systems and windows to handle hidden files - without changing things in > the unix userland (and without hacking windows to use dot files for these > files) it seems impossible to have a working cross-platform solution > without having to do some filename transformation. I would not expect a UNIX platform to hide the desktop.ini file. UNIX is not hiding files based upon attributes but based upon file names. > The last two ideas both involve imposing some restrictions on valid > filenames - on unix you could not have a file 'foo' and a file '.foo' > in the same directory. > > Do you have ideas other than the ones mentioned above? > We are willing to invest some time in the implementation of this but need > a clear statement whether the project wants some kind of implementation > and if so which approach is favored. Also some information on the > windows compile process (if needed) and maybe someone who volunteers you > help us in case we get stuck would be nice. The Windows build process is documented in the top-level of the openafs source tree in the README-NT file. Jeffrey Altman Secure Endpoints Inc.
smime.p7s
Description: S/MIME Cryptographic Signature
