lultimouomo
lultimouomo

Reputation: 248

java: check if a file can be moved under windows

I need to rename a file (keeping it in the same directory); I can't seem to find a way to see if my program has the required permissions:

Files.isWritable(directory) && Files.isWritable(oldFile);

always returns true, wether or not the running user has the permission to write the file (I guess they only check if the file is read-only, even if this violates the contract stated in the javadoc); I'm not running under a security manager so I can't call

System.getSecurityManager.checkDelete(oldFile.toString());

I need to check if the renaming of several files will (probably) succeed so I can't just try and catch the exception.
Is there a way out? Obviously a portable solution would be lovable but I would settle for a windows-specific one...

Upvotes: 0

Views: 893

Answers (3)

user207421
user207421

Reputation: 311023

Just try to move it! If the move failed, you didn't have permissions, or something else went wrong.

This is a general principle. Don't try to foretell the future, guessing whether an impending operation will succeed. Try the operation. Otherwise you introduce all sorts of extra problems:

  1. You might make the wrong test.
  2. The condition might change between the test and the operation.
  3. The operation usually returns an error or throws an exception anyway, which you have to write code to handle: why write it all twice?

Upvotes: 0

MSalters
MSalters

Reputation: 180145

Well, you can't check Windows ACLs that way. The "native" solution is fairly easy, since Windows supports transactions on the file system. Just call DeleteFileTransacted, and roll back the transaction if any one deletion fails.

If you're not using tranactions, then the second option is to first open handles with explicit DELETE desired access (DELETE is one of the standard WinNT access rights), denying any sharing. If and only if this succeeds for all files, delete them all with SetFileInformationByHandle(handle, FileDispositionInfo, &fdiObj, sizeof(fdiObj));

(The latter is not a transaction and may have Isolation issues as a result, which in turn affect Atomicity).

Upvotes: 1

Sarel Botha
Sarel Botha

Reputation: 12710

Try new SecurityManager().checkDelete(oldFile.toString()).

Upvotes: 0

Related Questions