Quoting Szakacsits Szabolcs <[EMAIL PROTECTED]>: > On Thu, 8 Feb 2007 [EMAIL PROTECTED] wrote: >> Quoting Szakacsits Szabolcs <[EMAIL PROTECTED]>: >> >> > Alright, convinced! From now on let's call it Release Candinate. Hopefully >> > this will open the gates for real bug reports, and if not then we'll have >> > a stable release real soon now. >> >> Courtesy of Florent Mertens, I have been getting regular NTFS-3g >> updates on my >> Ubuntu Edgy system. This update, which I installed last night, >> appears to have >> caused a regression with respect to using NTFS-3g to hold a local CVS tree. >> When I backed off to 0.20070118-BETA, but left the latest FUSE release >> (fusermount version: 2.6.3) unchanged, the problem disappeared. >> >> What I was seeing was intermittent problems reported by "cvs update": >> RCS file: /repo/x/foo.h,v >> retrieving revision 1.1 >> retrieving revision 1.3 >> Merging differences between 1.1 and 1.3 into foo.h >> cvs update: cannot change mode of x/foo.h: Operation not permitted >> x/foo.h already contains the differences between 1.1 and 1.3 >> >> Since the problem was intermittent I didn't get a chance to really >> investigate. > > Do you still have this problem? If yes, then is it reproducible if you do > a 'cvs update' again? What are the file permissions and owners for the > problematic local and cvs file?
No, this problem has been resolved. The cvs update command is now working for me very well. I did some adjusting of the mount options so that I would appear to be the owner of files created in the CVS checkout tree and that caused the errors to stop. Why the problem was intermittent, I don't know. Perhaps on some code paths, the cvs command doesn't treat this failure as fatal. In any case, I'm running version 1.0 and am a happy camper. Thank you. I appreciate you following up on this trouble report. Ted > Thanks, > Szaka > >> > The default_permissions FUSE option is transparently used from now if any >> > of the uid, gid, umask, fmask, or dmask mount option is used. This means >> > that probably many user will complain about "permission denied" errors. If >> > you want full access to everybody by default then don't use any of these >> > mount options. Otherwise you must configure them correctly. >> >> Could this be related? Since the problem was intermittent, I assume >> not. But >> maybe there is some second order effect? >> >> Here is what mount says: >> /dev/disk/by-uuid/0440226A402262A2 on /media/sda1 type fuseblk >> (rw,nosuid,nodev,noatime,allow_other,blksize=4096) >> However, in /etc/fstab we see: >> # /dev/sda1 >> UUID=0440226A402262A2 /media/sda1 ntfs-3g >> defaults,nls=utf8,umask=007,gid=46,show_sys_files 0 1 >> >> % /bin/ls -dl CVS/Entries >> -rwxrwx--- 1 root plugdev 1232 2007-02-08 17:08 CVS/Entries >> % grep plug /etc/group >> plugdev:x:46:haldaemon,ota >> % echo $user >> ota >> >> Ted Anderson ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
