Write Access Permission - Ideas and Call For Cases

[Mikenux]

Initial issue: #808

Goals

• Better protect files by making them read-only by default.
• Limit write access to files as much as possible, except for cases requiring permanent write access.

Discussion Goals

Below, different cases of write access to files and folders with initial ideas are presented.

The goal is to find out if your case matches one of the cases seen here. If not, report it and describe it as much as possible in relation to write access to files/folders. The reported case is subject to discussion. Also, tell me if there is anything missing in the cases presented. Comments and suggestions regarding the initial ideas are welcome, but this is not the main goal.

There is also an "App Focus Restriction" section. If you are opposed to it, please also detail your case.

Thanks!

Cases

File Saving and Export

• Ask to save or export one or more files.
• One file: For an existing file, window allowing to save under a different file name, to save the changes, or not to save the changes. For one file that is to be created, window to select the location to save it with editing of its filename.
• Multiple files: For existing files, window to save changes to all files, save copies to the location of these files, save copies to a specific location, or not save changes. For files to be created, selection of the location where to save them with the possibility of naming a project in the case of a folder containing these files; user can visually see the number of files and has the option to see the list of files.
• When saving changes, saved files are writable until the app is no longer running.
• If files are saved under a different file name or to copies, the original files remain read-only and only the new files or copies are writable.
• When the app is running again, ask again to save changes. For a file and if the file has already been saved previously, the portal window asks to overwrite it or save it under a different filename without directly displaying the location of the file to choose.

Save Location

• Fixed location where files can be saved.
• Examples: Documents folder, Downloads folder.
• Ask to select the location while having the possibility to create it.
• An app cannot access files already present in the selected folder if it has not already accessed them before.
• Write access to written files is valid until the app is no longer running.
• When running again, the app has read-only access to the files it has written.
• To be able to validate changes to the files again, their saving must be requested again. This is done in the same way as described in the "File Saving" section above.
• For downloads that can be resumed, use of "part" files. When a file is not completely downloaded, the app must use a "part" file extension to indicate that the file still needs to be written. This would allow the app to automatically gain write access to this file when it is launched again. Once the download is complete, the app will then use the standard file extension, and this file will then be read-only for the app.

Main File + Related Files

• A user-created and editable main file with app-created files. Related files created by the app have the same file name but with a different extension than the main file.
• Example: Database (main file) and log (related file created by the app).
• Use of the database of related files (see Related Files #1290).
• Grant write access to files related to a user-created file (i.e. the main file) if these are strictly created and modified by the app for proper operation. This is the case of the database example: the user mainly edits the database file, and the log is a file created by the app, not edited by the user, and which allows for the app to work properly. This is the rule for inclusion in the database of related files.
• This type of related files is requested when creating or opening the main file. Access to them is automatic.
• Question: Are there any cases where it is necessary for the main file to be permanently writable? If so, which ones and how do these cases work?

Folder with Permanent Write Access

• Specific folder containing files created by the app, but generally not edited by the user in relation to the operation of the app. This folder is somehow owned by the app but exposed in the user's file system. It can either be created by the app or selected by the user to use existing files (e.g. when using the app on another computer by migrating data). Files in this folder can be overwritten or updated.
• Examples: Backup folder, sync folder, build folder, game library (to update games).
• Use with related folders (see Related Files #1290): Whether the folder requiring automatic write access is a related folder or a folder within a related folder, the app must request to select it (creation is handled during this request if the folder does not exist). If this folder is a related folder, it must be in the related files database.
• Backup apps might use "part" files so that the system can monitor a backup job.
• Possible user experience: Ask to select a folder by describing the case and giving examples. Options to select an existing folder and create an empty folder. Recommend creating an empty folder if no data exists for the purpose of the app or to keep the original data.
• Question: Would it be useful to have system-side indicators that a folder "is owned" by an app and to inform the user when files are moved to that folder (and then have the option to make copies instead of moving files)?

Temporary Files

An app can automatically write temporary files to display previews. For example, this is the case for previewing a TEX file with a DVI file. If the preview is supposed to be permanent, it is recommended to save it, so use the file saving mechanism.

App Focus Restriction

• All write access is revoked when the app does not have focus. Write access is only allowed when the app has focus.
• When the app has the focus again, it again has write access to the files to which it had write access before losing the focus.
• For the "File Saving and Export" case, the app can continue to write (to) a file if the operation started when the app had the focus. The same goes for files to be written to a Save Location.
• For the "Folder with Permanent Write Access" case, the current direction is to overcome the app focus restriction by registering scheduled tasks. The app can continue writing (to) files if the operation started when the app had the focus.

Cases Requiring Thought

• Thumbnail creation
• App-specific files like config files (if it happens that having app-specific files read-only is important)

[Mikenux]

Proposal Updates

[Mikenux]

Update 1

• Main File + Related Files: Added when to request such related files.
• Folder with Permanent Write Access: Added use of a folder with permanent write access when using related folders.

View the most recent edit using the "edited" button in the proposal.

[Mikenux]

Update 2

• File Export is the same as File Saving.
• Add a Temporary Files section which includes a note on file preview.

[Mikenux]

Update 3

• Add a section "Cases Requiring Thought"