![]() | |||||||||||||
Messages in this thread |
> Would you take a look at it? The patch looks fine, similar to mine, I also used a flag when trying to send a zero attribute to the server, but removed it later to reduce the number of differences. >> I made another small change: The ATTR_READONLY is only cleared if all >> writeable bits are set in the Linux permissions (the file is writeable for >> user, group and others). This is caused by the check ((mode & >> S_IWUGO) == S_IWUGO). I think that this does not make sense, as soon >> as any write flag is set, the file is no longer read-only.>> I agree that the 2nd change is intuitive, but it changes behavior slightly > more - and this close to the next point release coming out I would > rather fix the bug the least risky way. The current behavior is not only unintuitive, it is also inconsistent. When having a file_mode of 0755, read-only files on the Windows share have permissions "-r-xr-xr-x" on the CIFS client, and writeable files "-rwxr-xr-x". However, to make a file writeable, setting its permissions to "-rwxr-xr-x" is not sufficient, you have to set "-rwxrwxrwx". When setting permissions from the shell or a file manager, it is possible to cope with it, however, if an application has to control the read-only state, you have to set the file_mode to 0777, the umask to 0000 and hope that this will make the application set all writeable bits. We have people that use subversion working copies on Windows shares and want the read-only attribute to be set correctly when locking and unlocking files. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2007-03-28 09:19 [from the cache] ©2003-2008 | |||||||||||||