571335_ja-JP

liliconcom

ディレクトリが書き込み可能である場合、ディレクトリが書き込み可能な場合は 0 を返します。以前にネットワークドライブへの読み取り専用アクセス権を持っていたユーザーに、読み取り書き込みアクセス権が与えられた場合でも、アクセス権が付与された後、ディレクトリ内にいるときにディレクトリ writable() が 0 を返すという問題があります。 ユーザーは、問題のディレクトリ内のフォルダーを開いたり、ファイルを作成したり、ファイルを更新したり、ファイルを削除したりできることを確認しました。 他の人も以前にこの問題を抱えています。 このため、保存ディレクトリに関するデータ検証の設定が困難になっています。自動化とスクリプト作成ウィンドウズRe: ディレクトリが書き込み可能である場合、ディレクトリは書き込み可能ですは 0 を返します私の推測では、あなたの言うことは正しいと思います。 私の IT グループは、ユーザーが有効になるように最初の書き込みステータスを更新しているだけだと思われます。 ただし、jmp は、書き込み可能なディレクトリのユーザー権限を更新して 0 を返すときに、2 番目の「ancient」フィールドが読み取り専用ではない (完全にチェックされていない) ことを要求している可能性があります。 そして、私の IT チームは、その場所も修正する必要があることに気づいていません…

エンドツーエンドのテストではないのは当然です。 明らかに読み取り/書き込みアクセス権があるためです。

事前に is is directory コマンドを実行して、パスが正しく入力され、存在していることを確認してください。 そして、1を返します。 最初の健全性チェックとしてそれを提案していただきありがとうございます。

また、IT 部門にそのディレクトリのドライブ マッピングを確認するよう依頼します。 解決策が見つかったらまた確認します。

JMPが実行しているチェックのためにサブインできる、ディレクトリ書き込み可能のエンドツーエンドバージョンを実行するjslスクリプトを持っている人はいますか? この問題の長期的な解決策としては、それがより良いかもしれません…Re: ディレクトリが書き込み可能である場合、ディレクトリは書き込み可能ですは 0 を返します

IsDirectoryWritable() の前に IsDirectory() を使用してパスが存在することを確認します。 ディレクトリが存在しない場合 (スペルミスなど)、IsDirectoryWritable はエラーではなく false を報告します。 IsDirectory() は、不正な名前に対して false を報告します。 おそらくドライブマッピングの問題でしょうか?

 

私の簡単なテストでは、この関数は実際にはエンドツーエンドのテストを行っているのではなく、Windows のアクセス許可をテストしているようです。 VirtualBox に接続されている Linux ドライブの場合、Linux 権限に関係なく、常に true (書き込み可能) と報告されます。

 

私が見たものは次のとおりです。

User PermissionsUser Permissionsユーザー権限Admin PermissionsAdmin Permissions管理者の権限

管理者ではなくユーザーとして実行しており、書き込み権限のないフォルダーには isDirectoryWritable==false が設定されています。

 

最後に、関与していないと思われる古代のオプションがあります。

Directories don't really have a read-only attribute.Directories don't really have a read-only attribute.ディレクトリには実際には読み取り専用属性はありません。

その四角は 3 番目の状態であり、チェックされているかチェックされていないものではありません。

https://superuser.com/questions/1580751/folders-created-with-read-only-attribute-and-i-cannot-remove