Enthuware

Posted: **Thu Mar 03, 2016 4:19 pm**

Regarding the note:

NOTE: Some candidates have reported being tested on StandardCopyOption.ATOMIC_MOVE. Unfortunately, it is not clear whether the exam tests on the implementation dependent aspect of this option. If you get a question on it and the options do not contain any option referring to its implementation dependent nature, we suggest the following: Assume that the move operation will succeed and then the delete operation will throw a java.nio.file.NoSuchFileException.

Assume the move operation will succeed? Or do you mean disregard the ATOMIC_MOVE copy option and evaluate the call to move() on its own merits, as if it didn't have the ATOMIC_MOVE copy option? In this question, for example, the two paths don't locate the same file, so the operation would fail. The API for Files.move() states that:

By default, this method attempts to move the file to the target file, failing if the target file exists except if the source and target are the same file, in which case this method has no effect.

In this case, Files.isSameFile(p1, p2) returns false, so the move operation would fail.

Posted: **Thu Mar 03, 2016 9:31 pm**

The JavaDoc for Files.move clearly says that when the option is ATOMIC_MOVE, the outcome is platform dependent if the target file exists. So why would you want to assume, "disregard the ATOMIC_MOVE copy option and evaluate the call to move() on its own merits"? If that were the case, they would have said it in the JavaDoc itself, no?

Paul.

Posted: **Fri Mar 04, 2016 2:39 pm**

But if you try to move two files and the target file already exists, the operation fails.

The actual question says:

Assuming that a file named "a.java" exists in c:\pathtest\ as well as in c:\pathtest\dir2, what will happen when the following code is compiled and run?

Surely if there was no mention of the implementation-dependent nature of StandardCopyOption.ATOMIC_MOVE, we would have to assume that the move operation failed.

Posted: **Fri Mar 04, 2016 3:34 pm**

I do apologise, you are right.

I ran some code to test the two different options:

Code: Select all

        Path p1 = Paths.get("c:\\temp\\text.txt");
        Path p2 = Paths.get("c:\\temp\\dir\\text.txt");
        Files.move(p1, p2); //FileAlreadyExistsException
        System.out.println(p1.toFile().exists() + " " + p2.toFile().exists());

Code: Select all

        Path p1 = Paths.get("c:\\temp\\text.txt");
        Path p2 = Paths.get("c:\\temp\\dir\\text.txt");
        Files.move(p1, p2, StandardCopyOption.ATOMIC_MOVE); //File is moved successfully!
        System.out.println(p1.toFile().exists() + " " + p2.toFile().exists());//false true

And it looks like, when the StandardCopyOption.ATOMIC_MOVE is passed into Files.move(), the operation completes successfully - even when a file with the same name already exists in the target directory. I still find it bizarre how the behaviour changes, but I guess will just have to accept it.

Thank you very much for highlighting this issue!

Posted: **Fri Mar 18, 2016 1:51 am**

If Files.move(p1, p2, StandardCopyOption.ATOMIC_MOVE); move file,
then
Files.delete(p1); throw an exception at run time.

If Files.move(p1, p2, StandardCopyOption.ATOMIC_MOVE); not move file (we would have to assume that the move operation failed.),
then an IOException could be thrown. (java.nio.file.NoSuchFileException)

So, anyway "It will throw an exception at run time",
but not "The outcome is JVM/platform dependent"

Your answer is incorrect.

Posted: **Sat Mar 19, 2016 10:14 am**

You are right. Fixed.
thank you for your feedback!

Enthuware

About Question enthuware.ocpjp.v8.2.1805 :

About Question enthuware.ocpjp.v8.2.1805 :

Re: About Question enthuware.ocpjp.v8.2.1805 :

Re: About Question enthuware.ocpjp.v8.2.1805 :

Re: About Question enthuware.ocpjp.v8.2.1805 :

Re: About Question enthuware.ocpjp.v8.2.1805 :

Re: About Question enthuware.ocpjp.v8.2.1805 :