BG - Ben Armstrong wrote:

Also, I still don't understand why a workaround is not possible.  If
there is no workaround, several otherwise useful Unix applications
(Subversion is the one I'm interested in today, but there are others)
cannot operate on Samba ODS-2 shares because they heavily rely on files
kept in directories with dots in them.

The filename translation routines in SAMBA 2.0.6 could certainly deal with the extra dots in the directories.

ODS-5 does not need any of the filename mangling, and should not need any special casing.

And nothing in the SAMBA source code really needs ODS-5 filenames, the proper solution is to make the filename support on OpenVMS to be two VFS modules. I recall only one case where SAMBA 2.X is using a filename that is not compatible with ODS-2, and per the SAMBA coding practices, it is a bug because those filenames should be set in the CONFIGURE, with a default value if they are not set. I have not checked if that bug is fixed in SAMBA 3.x, but if not, it is something that a patch can probably be written for that they will accept.

One For ODS-5 which basically will not do much, and one that has all the work arounds for ODS-2, and this would be designated by a share parameter.

Right now, one of the hassles in the filename mangling is identifying if the volume based on the given pathname is ODS-5 or not, and that requires either keeping track of the default device, or otherwise looking up the information on the fly.

The VFS approach simplifies all of this.

The VFS approach also would make it easy to add a VFS that exposed multiple versions of a file for some shares.

-John
[EMAIL PROTECTED]
Personal Opinion Only


PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING:

http://www.catb.org/~esr/faqs/smart-questions.html

Reply via email to