write-permissions -- Exception occurs when you try to save a book and don't have permissions

[deyan]

Make a dialog that says "You don't have permissions to write in this directory". The dialog should appear when trying to save a book on a prohibited location and when closed should bring save as dialog back.

[deni]

• Actually there is no exception - the save as dialog is closed and an error message that the book could not be saved appears.
• However, I agree having a more specific error message and leaving the file dialog open, will be more convenient for the user.

[deni]

• In FileDialog.performFileCheck(FileDialogInput, File[]) when we try to save something as file, check whether we can write in the specified directory. This can be done in the following way:
  • If file is the file we want to save the book as, then parentDir = file.getParentFile() is the directory where it is.
  • Calling parentDir.canWrite() will check whether the directory exists and whether we can write in it. This is exactly what we need.

[pap]

• Following are the experience reviewer notes. They might be a bit unclear. We made several builds with different corrections. In the attached file imr.patch you can see the code as it was when we finished the review. :

• At first the files couldn't be saved neither in Program Files folder, nor on the desktop, however the user was able to create a new folder using the button in the file dialog and save book in it. With the latest zip the user is able to save books on the desktop, but there are some other issues listed below.
• With the first builds the dialogs that appeared on Windows and Mac OS X differed from those that appeared on Linux.
• On Windows and Mac OS X, there was the following bug:
  • If you try to export resource to place with no permissions, the first time a dialog message appears, but when you try to export the resource again on that place, exception is thrown.
  • The same happens if you try to overwrite a resource when it is located on place with limited access.
• With the last zip, each time the user tries to save book or export resource, the application acted as if the book is already saved and asks the user whether he would want to overwrite it. If the user select yes, the book is saved, if the user select no, the book is saved again.

• Implementaion remarks:
  • On windows and probably MacOS the method File.canWrite doesn't work correctly. So it is better to use a try{}catch(IOException e){} to do the check.
  • However that needs to be better synchronized with the check for file existence.
  • Also you should not only check if you can write in the parrent directory but if you can write in the file itself if it exists

[deyan]

Batch update from file priorities8.csv

[stefan]

I made only minor change of the imr.patch. Tested on win - there were no exceptions in saving book or exporting resource in not-permited folders. Design-related code:

if (inputKind.equals(FileDialogInput.Kind.SAVE)) {
			assert input.isMultiSelectEnabled() == false : "Cannot save in multiple resouces!";

			boolean writable = true;
			if (OSUtil.isWindows() || OSUtil.isMacOS()) {
				try {
					boolean created = files[0].createNewFile();
					if (created) {
						files[0].delete();
					}
				} catch (IOException e) {
					SophieLog.info("File doesn't seem writable", e);
					writable = false;
				}
			} else {
				writable = files[0].getParentFile().canWrite();
				writable = writable && (files[0].exists() && files[0].canWrite());
			}
			if (!writable) {
				DialogUtils.showErrorDialog(this.fileChooser.getParent(),
								"You don't have permissions to write in this directory.",
								"Permission denied");
				return null;
			} 

[pap]

• Commited in [9185].
• The flow of logic for Linux wasn't the same as for Windows/MacOS.

[meddle]

Closing all the tickets before M Y1