3

VistaおよびWindows7のUsersグループのメンバーが、昇格せずに書き込み権限をデフォルトで持っているフォルダーを見つけようとしています。

これは、すべてのユーザーが共有および書き込み可能である必要がある共通データ（データベースおよび定期的に更新されるドキュメントパック）の保存に使用されます。

Vistaではc：\ ProgramDataに解決されるCSIDL_COMMON_APPDATAをどこかに持っていたと思いましたが、テストでは、ユーザーグループのメンバーは、マシンがドメインに参加している場合にのみ読み取り/実行権限を持っていることがわかりました。これはドキュメントと矛盾しているようです。

CSIDL _ COMMON _ AP​​PDATA（FOLDERID_ProgramData）バージョン5.0。

すべてのユーザーのアプリケーションデータを含むファイルシステムディレクトリ。一般的なパスは、C：\ Documents and Settings \ All Users \ApplicationDataです。このフォルダーは、ユーザー固有ではないアプリケーションデータに使用されます。たとえば、アプリケーションは、スペルチェック辞書、クリップアートのデータベース、またはログファイルをCSIDL_COMMON_APPDATAフォルダに保存できます。この情報はローミングせず、コンピューターを使用しているすべての人が利用できます。

http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx

ドキュメントフォルダ（CSIDL_COMMON_DOCUMENTSなど）を使用したくないのは、これらのファイルがユーザーに特に表示されないようにするためです。

興味深いことに、CSIDL値をパスに解決するために使用するコードを次に示します。

public enum CSIDL : int
{
  COMMON_APPDATA = 0x0023
  // etc
}

public static class Folders
{
  [DllImport("shell32.dll")]
  static extern bool SHGetSpecialFolderPath(IntPtr hwndOwner, [Out]StringBuilder lpszPath, int nFolder, bool fCreate);

  public static string GetCsidlValue(CSIDL csidl)
  {
    StringBuilder path = new StringBuilder(260);
    SHGetSpecialFolderPath(IntPtr.Zero, path, (int)csidl, false);
    return path.ToString();
  }

  public static string GetCommonAppDataFolder()
  {
    return GetCsidlValue(CSIDL.COMMON_APPDATA);
  }
}

助言がありますか？

編集：System.Environment.SpecialFolderを使用しない理由を尋ねました。その列挙で定義されていないフォルダー（COMMON_DOCUMENTS-0x002e）を使用します。

public enum SpecialFolder
{
  ApplicationData = 0x1a,
  CommonApplicationData = 0x23,
  CommonProgramFiles = 0x2b,
  Cookies = 0x21,
  Desktop = 0,
  DesktopDirectory = 0x10,
  Favorites = 6,
  History = 0x22,
  InternetCache = 0x20,
  LocalApplicationData = 0x1c,
  MyComputer = 0x11,
  MyDocuments = 5,
  MyMusic = 13,
  MyPictures = 0x27,
  Personal = 5,
  ProgramFiles = 0x26,
  Programs = 2,
  Recent = 8,
  SendTo = 9,
  StartMenu = 11,
  Startup = 7,
  System = 0x25,
  Templates = 0x15
}

編集：私は答えられない質問をしたと思います。

http://blogs.msdn.com/oldnewthing/archive/2004/11/22/267890.aspx

これは、これが意図的に不可能にされていることを意味しているようです。その後、昇格されたCLIアプリケーションを使用してフォルダーのACLを変更することに戻りました。汚れていますが、私たちの場合は必要です。

4

1 に答える 1

3

http://blogs.msdn.com/oldnewthing/archive/2004/11/22/267890.aspx

これは、これが意図的に不可能にされていることを意味しているようです。次に、管理者特権の CLI アプリケーションを使用してフォルダーの ACL を変更します。汚いですが、私たちの場合に必要です。

于 2011-03-25T08:57:01.020 に答える