pl->fs: please have a look

I opened this issue because I am (in my copious spare time) the maintainer of
GTK+ on Windows, and a user complained that the GTK+ file chooser shows drives
that should be hidden. I then realized that the same probably goes for OOo's own
file picker, too.

Anyway, it seems that the code required to determine which drives should be
hidden is very simple: One just has to look at a DWORD value in the Registry,
which is a bitmask, one but per drive letter. See
http://support.microsoft.com/kb/179221  That knowledge base article claims that
it applies to Win98 and NT4, but presumably they just haven't updated the
article text and it holds for current versions, too.

Yeah, drive letters are a kinda stone age concept... I don't know whether there
are other more modern ways to limit the browseability of network shares, or
mounted volumes. But anyway, as a first cut it would be nice to at least obey
the NoDrives setting.

How to integrate such a check in a clean way into the OOo OfficeFilePicker I
can't say. I could come up with a patch suggestion, unless you tell me you
aren't interested?

We're always interested in patches. However the file picker itself might be the
obvious but not necessarily the right choice since it is system agnostic. It
might be that the correct place to implement this would be the actual file layer
in the sal project or perhaps a registry layer (because the file picker uses UCB
services as far as i know which already can exclude some configured paths,
though configured not in the system registry but in OOo's registry). However I
think fs might have something to say on that.

fs->tml: thanks for the hints how to solve this, and thanks for the offering. Of
course there's no reason why we shouldn't be interested in a patch.

Unfortunately, as Philipp said, the file picker would be the wrong place. It
uses the UCB (universal content broker), and I think a patch should be therein -
in ucb/source/ucp/file, I suppose. I'm cc'ing abi here, I suppose he also has an
opinion.

fs->abi: Would you agree that the file UCP is the proper place to respect the
hidden drives, or should this even be one layer below, in OSL?

The intent of this policy setting is not to prevent application code from
accessing some drives altogether. (The user who asked for this in the GTK+ file
picker said that their site prevents end-users from browsing their local C:
drives. I assume apps are still installed on local drives on that site by
sysadmins. It would be rather silly if apps could not access the local drive to
read their own data files, store temp files or whatnot. )

I guess the policy is more supposed to be just a "hint" to cooperating software
(like Explorer, and Microsoft's own file open dialog) to prevent unsophisticated
users from casually browsing "hidden" drives interactively.

I don't think it would be correct to block access to the "hidden" drives
altogether at lower levels in OOo. I suspect sysadmins on sites that use a
policy like this are well aware that determined users can circumvent it, for
instance by using VBA or whatever scripting in some app.

(Personally I think such a policy is then rather pointless and just false
security. But... some customer might think it is useful and perhaps then avoid
OOo because it provides a trivial way to get around the policy.)

Perhaps the OfficeFilePicker should call some optional functionailty in the UCP
like "prefixIsHiddenByPolicy" or whatever that would check if a URI is in a
subtree hidden in some platform-dependent way. On Win32 this would be done by
checking the NoDrives value.

This in fact doesn't sound as if it belongs into OSL, or even only UCB. Seems to
be a mere UI "feature", somewhat complementary to
http://ui.openoffice.org/specification/FileDialog_RestrictedPaths.sxw.

Accepting, Targeting. I don't consider this important enought for 2.x - but
would accept and integrate a patch, of course ;)

Reset assigne to the default "issues@openoffice.apache.org".