Tuesday, September 21, 2010

SOP 1: Avoid Changing File Access from Your Program

If you’re program reads/writes to a file or folder that has restrictions (i.e. read-only, or limited user access) and you’re deciding whether to change these access settings – I'd say don’t bother.

filepermission

I’ve heard/seen this many times before in a programming situation: the program needs to write to a settings file, but the settings file is marked as read-only. So, in his code, he turns off the read-only access flag (or turns on the write-flag, whatever) for the file so he’d be able to save again. This one is simple enough and maybe okay. This is good, i guess, since your program sort of owns that file.

However, for other but similar cases, I'd rather not change anything about the file access (or folder access). If it is read-only, then let it be! Just display a message to the user that you cannot save to that file and let the user handle it. Why? Here are some of MY reasons:

1. The read-only flag (or similar) was set there for a reason. Your program can’t exactly know that reason, so don’t try to forfeit it.

2. Removing the read-only flag can be easy for most cases, but what if that restriction is set for user security (i.e. Admin privileges, User-based permissions) – suddenly, your code would blow up just so you can set a file flag.

3. Testing your code/program for the multitude of combinations for permissions would take more time and effort than necessary.

Unless, your developing a System Utility Tool (or similar) then i suggest to just avoid changing file security/access settings altogether.

Of course, THIS is just me.

0 comments:

Post a Comment