权限问题引发的bug

大清早还在睡着, 被电话叫出来说软件出问题了T_T, 说软件不能解析某个文件.

软件挑文件这毛病还从没遇到过, 先把管理员权限, 文件路径是否存在等问题全部确认后没有发现异常.

万般无奈情况下, 荒谬的猜测代码打开文件时要求了写权限(如:fopen(file_path, “rb+”)), 而这个文件恰好被设置了只读属性, 会导致打开失败, 打开代码一看果然如此, 使用CreateFile, 但是却带有GENERIC_WRITE权限的要求.


发一下牢骚 🙂

这其实是一个典型的权限问题, 在此之前曾经碰到过, 在Win7以上系统下看不到网络驱动器, 后来发现在Win7以上Admin权限是不显示网络驱动器的, 这也是Windows自身提供的一种保护机制.

因此在对于与权限有关的代码上要格外小心, 如果打开一个文件只需要读, 那么你就以只读打开就好了, 不必用读写或者以不存在就创建方式来打开. 对于只读数据场合来讲, 在你要了写权限之后就有一定风险去窜改, 这是一件极度危险的事.

说到权限就再扯两句.
目前软件的文件浏览是client通过socket远程查询server那台电脑上的所有文件, 然后以自定义的文件浏览框来显示, vincnet曾指出在以windows下的domain的组网方式中, 有些domain访问是要输入特别的帐号与密码的, 以这种C/S的方式去加载文件必然不能解决domain的帐号密码问题, 事实上, 如一些大的生产厂商正是使用此种方式将烧录文件放在domain服务器上, OP人员禁止私自将烧录文件copy到本机电脑的, 如果需要烧录某文件, 必须使用网络驱动器直接加载. 目前他们还是手动copy到本地再烧录的, 这势必会成为另一个大坑.

其实也并非没有解决方案, 但是对于目前的软件结构来讲, 要变的东西太多, 就只能先使用鸵鸟算法了 ^_^!



评论

  1. […] demo UI做完之后, 老板提出新的设想, 他觉得把数据处理部分和UI逻辑处理部分混合做在一起不好, 他觉得整个软件应该分成两块, 一个只是处理用户逻辑, 一个用于处理所有数据作业. 提到这种架构,我不得不说一句, 虽然老板是搞FPGA的, 但是他这一观点真的很不错, 与大名鼎鼎的MVC模式有不谋而合的味道, 后来我在做UI时采用了类似的方法. 然后我们就把逻辑处理部分定义为后台, 也就是TCP端的server端. 但是Server一词被引入后老板就开始有点胡思乱想了, 他觉得要把软件做成UI可远程控制的模式, 于是我们花大力气去做远程文件浏览器等很多不必要的复杂设计. 现在软件开发已经快结束了, 我可以很负责任的说这完全是过度设计, 为了所谓远程操作功能, 我们不得不在设计上牺牲很多其他功能以保证这个功能的实现, 而且至目前为止这种设计可能还残留着一个大坑. […]

发表评论