File Folderitem isReadable

  1. last year

    Tim T

    16 Feb 2017 Atlanta, GA

    My software opens data files and then saves data changes back.

    The files created or installed do NOT have the read only bit set.

    However, just had a customer get a bunch of errors because the file is set to read-only.
    Or perhaps the folder is. I don't know.

    I found the .Permissions option in the documentation but it says it only works on OS X and Linux.
    I need something that works on Windows.

    If it's my software's file I should be able to detect read only and remove that from the file so they can write safely to it???

    I am not talking about a locked file either, although perhaps I can check for that too.

  2. Michel B

    16 Feb 2017 Pre-Release Testers

    Where is the data file ?

  3. Tim T

    16 Feb 2017 Atlanta, GA

    In the Documents tree for the user.

  4. Michel B

    16 Feb 2017 Pre-Release Testers
    Edited last year

    I would suggest you move your work files to a subfolder in SpecialFolder.ApplicationData, where you always have read and write privileges. And they will be save from undue manipulations.

    Then provide the user with an option to save or load the file. In the file menu for instance.

    Documents folder can be off limit for several different reasons. The PC administrator can perfectly well decide apps cannot update files in Documents without user intervention (Save dialog). And since the mechanism differs considerably from CHMOD on Mac and Linux, there is no simple way to change that.

  5. Tim T

    16 Feb 2017 Atlanta, GA

    Microsoft says to put user created documents in the Documents folder as far as I have been told (or read).

  6. Michel B

    16 Feb 2017 Pre-Release Testers
    Edited last year

    You don't understand. The way Windows applications work is not by modifying directly documents in the Document folder.

    User loads the document into the app, then he uses the option Save as to save the document. Which automatically grants the app access to the file. On Mac the fact to open it with a dialog grants write access. I don't know if it is the case under Windows.

    Working directly on the user file is dangerous. Imagine you experience a problem during save. The user file is gone.

    That is why it is recommended to copy the file within ApplicationData, modify it there, and when the user saves, copy it to the place he wants to. In case of issue, you still have a copy.

or Sign Up to reply!