Re: svn delete removes read-only files
C and C++ programs do not use the um command internally. They use unlink, which is what the rm commad uses internally, which I see scattered throughout the source code. C functions are not going to be interactive unless someone actually programs in a deliberate interaction. That said, I can attest that rm has been doing this for at least 15 years. My memory is hazy about it, but I *do* think this was the behavior in BSD 4.2, 25 years ago. On Wed, Nov 20, 2013 at 12:44 AM, David Chapman dcchap...@acm.org wrote: On 11/19/2013 6:28 PM, Ryan Schmidt wrote: On Nov 18, 2013, at 10:37, Rick Varney wrote: So for Redhat 5, rm does seem to give read-only files some special treatment. The fact that rm on your OS does not makes me wonder if I am wrong about how typical this behavior is in other Linux/Unix flavors. Both GNU rm (used on Linux) and BSD rm (used on OS X and *BSD) do this. From the BSD rm manpage on OS X 10.9: It's quite possible that I haven't read the rm man page since the 1980s. :-) Also, the only time I tend to have read-only files is when I am running as superuser, in which case I run rm -f to get rid of stuff without the prompt from the rm -i alias that is the default within the superuser account. So I have never seen the prompt. For the record, my machines mostly run CentOS, so they have the behavior described. I just confirmed this by creating a read-only file in a non-superuser account. Guess I learned something today. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: svn delete removes read-only files
On Nov 18, 2013, at 10:37, Rick Varney wrote: So for Redhat 5, rm does seem to give read-only files some special treatment. The fact that rm on your OS does not makes me wonder if I am wrong about how typical this behavior is in other Linux/Unix flavors. Both GNU rm (used on Linux) and BSD rm (used on OS X and *BSD) do this. From the BSD rm manpage on OS X 10.9: DESCRIPTION The rm utility attempts to remove the non-direc- tory type files specified on the command line. If the permissions of the file do not permit writing, and the standard input device is a ter- minal, the user is prompted (on the standard error output) for confirmation.
Re: svn delete removes read-only files
On 11/19/2013 6:28 PM, Ryan Schmidt wrote: On Nov 18, 2013, at 10:37, Rick Varney wrote: So for Redhat 5, rm does seem to give read-only files some special treatment. The fact that rm on your OS does not makes me wonder if I am wrong about how typical this behavior is in other Linux/Unix flavors. Both GNU rm (used on Linux) and BSD rm (used on OS X and *BSD) do this. From the BSD rm manpage on OS X 10.9: It's quite possible that I haven't read the rm man page since the 1980s. :-) Also, the only time I tend to have read-only files is when I am running as superuser, in which case I run rm -f to get rid of stuff without the prompt from the rm -i alias that is the default within the superuser account. So I have never seen the prompt. For the record, my machines mostly run CentOS, so they have the behavior described. I just confirmed this by creating a read-only file in a non-superuser account. Guess I learned something today. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: svn delete removes read-only files
David Chapman dcchapman at acm.org writes: On 11/15/2013 3:57 PM, Rick Varney wrote: Branko Čibej brane at wandisco.com writes: It really depends on what you think Unix rm actually is. The unlink() or remove() functions don't care about permissions on the target, only that you have write permission on the parent directory. It does not surprise me to hear that system functions don't care about file permissions. The OS flavor I'm most familiar with is rhel5. Here is how the interactive rm command behaves in this case: $ ll foo.txt -r--r- 1 usb00219 nxp 4 Nov 15 15:42 foo.txt $ rm foo.txt rm: remove write-protected regular file `foo.txt'? y So while rm is perfectly capable of removing the read-only file in a directory where I have write permissions, it politely asks first. I had assumed the rm command behaves similarly on many flavors of Unix (as well as Linux). This is probably due to an alias set up in your login script, e.g. .bashrc. Type alias at the command prompt; you will probably find that rm is aliased to rm -i, which prompts before removing files. rm does not prompt like this by default. ll is not a Unix/Linux command either, so it's a pretty safe bet that you have aliases set up, either in the distro you have installed, or configured by your sysadmin (on my CentOS machines, this alias is present only for the root account by default). Try \rm foo.txt (backslash before executable name); I'll bet that it does not ask you for permission to remove a write-protected file. You are right that I have an alias for ll: alias ll='ls -l' I looked at my aliases and grepped through my .bashrc files - no alias for rm appears to be set. The \rm experiment still behaves the same way for a read-only file: $ \rm foo.txt rm: remove write-protected regular file `foo.txt'? y There is a rm -i switch. When I give it, rm then prompts before removing files that are not write protected: $ touch foo.txt $ rm -i foo.txt rm: remove regular empty file `foo.txt'? y This is not the usual behavior I see. Finally, I found a snippet from the rm manpage on rhel5 that speaks to this: If a file is unwritable, the standard input is a tty, and the -f or --force option is not given, rm prompts the user for whether to remove the file. If the response is not affirmative, the file is skipped. So for Redhat 5, rm does seem to give read-only files some special treatment. The fact that rm on your OS does not makes me wonder if I am wrong about how typical this behavior is in other Linux/Unix flavors. Best regards, Rick
Re: svn delete removes read-only files
Branko Čibej brane at wandisco.com writes: Maybe this behavior can be made optional, enabled via the configuration file? Changing client behaviour via config file options is almost always a bad idea ... every such option makes testing more complex and bug triage more time consuming. I'm not saying that there's no chance we'd ever change the way 'svn delete' behaves; I only stated some of the arguments against that, and there can certainly be other opinions. But we'd have to see some indication that the case you describe is actually moderately common. Frankly, I doubt it is; because mandatory locking isn't, in my experience, a very common workflow with Subversion. I'm finding myself in agreement that such customizations are generally not a good idea. I would be interested to hear if others using a mandatory lock workflow have felt this svn delete behavior is an issue. Best regards, Rick
Re: svn delete removes read-only files
Branko Čibej brane at wandisco.com writes: I disagree with the behaviour change because it makes 'svn delete' in the presence of svn:needs-lock behave exactly opposite to every other command. IMO, it's quite enough to simply fix the bug where we try to change the permissions on a non-existent local path. So I suggest you file a bug for that, not for the behaviour change. In general I understand the point about behavior consistency, and I agree this is important. By behave opposite you mean that if 'svn delete' changes its behavior in the presence of svn:needs-lock, this would be opposite of other commands that ignore whether it is present? My suggestion is not to look for the presence of svn:needs-lock, but to honor file permissions when doing 'svn delete', irrespective of whether svn:needs-lock is set. I think there would be symmetry between this behavior and how svn currently handles file permissions: svn makes files with svn:needs-lock present read-only if no lock is set, so users that try to edit the file notice it is read-only, and take appropriate action - get the lock. In the same way, if 'svn delete' warned about or refused to delete read-only files, the user would be reminded to get the lock. This behavior is similar to how the unix rm command behaves. I think this would be more intuitive. We won't fix this in 1.6 and 1.8 is already fixed: $ svn rm wc/A/f D wc/A/f $ svn st wc/A/f D wc/A/f $ svn lock wc/A/f 'f' locked by user 'pm'. $ svn st wc/A/f DK wc/A/f Yes, I was just going to say. I added test cases for this on trunk, and they passed; I've just been running them on 1.8, where they pass as well. In other words, upgrading to 1.8 will fix the issue, and in the meantime, ask your users to either revert the delete first (i.e., 'svn revert file; svn lock file; svn rm file; svn commit', or to use the URL in the 'svn lock' command. And here's the related issue:http://subversion.tigris.org/issues/show_bug.cgi?id=4304 Good - I agree the error message on lock/unlock is a bug, and it is good to know that it is now fixed. Best regards, Rick
Re: svn delete removes read-only files
On 15.11.2013 20:30, Rick Varney wrote: Branko Čibej brane at wandisco.com writes: I disagree with the behaviour change because it makes 'svn delete' in the presence of svn:needs-lock behave exactly opposite to every other command. IMO, it's quite enough to simply fix the bug where we try to change the permissions on a non-existent local path. So I suggest you file a bug for that, not for the behaviour change. In general I understand the point about behavior consistency, and I agree this is important. By behave opposite you mean that if 'svn delete' changes its behavior in the presence of svn:needs-lock, this would be opposite of other commands that ignore whether it is present? My suggestion is not to look for the presence of svn:needs-lock, but to honor file permissions when doing 'svn delete', irrespective of whether svn:needs-lock is set. You're allowed to modify and commit changes to a file that has the svn:needs-lock property regardless of whether it's locked or not. svn:needs-lock is not a constraint, it's just a reminder. svn delete is not, and should not be, special. FWIW, I've seen editors that automagically make a file writable if you start modifying it ... I think there would be symmetry between this behavior and how svn currently handles file permissions: svn makes files with svn:needs-lock present read-only if no lock is set, so users that try to edit the file notice it is read-only, and take appropriate action - get the lock. In the same way, if 'svn delete' warned about or refused to delete read-only files, the user would be reminded to get the lock. This behavior is similar to how the unix rm command behaves. It really depends on what you think Unix rm actually is. The unlink() or remove() functions don't care about permissions on the target, only that you have write permission on the parent directory. Given that you can lock a deleted file, I really don't see a problem. If Subversion started prompting the user in such cases, the change in behaviour might break scripts for people who depend on the Unix-like delete behaviour, where file permissions don't matter but directory permissions do. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: svn delete removes read-only files
Branko Čibej brane at wandisco.com writes: On 15.11.2013 20:30, Rick Varney wrote: Branko Čibej brane at wandisco.com writes: I disagree with the behaviour change because it makes 'svn delete' in the presence of svn:needs-lock behave exactly opposite to every other command. IMO, it's quite enough to simply fix the bug where we try to change the permissions on a non-existent local path. So I suggest you file a bug for that, not for the behaviour change. In general I understand the point about behavior consistency, and I agree this is important. By behave opposite you mean that if 'svn delete' changes its behavior in the presence of svn:needs-lock, this would be opposite of other commands that ignore whether it is present? My suggestion is not to look for the presence of svn:needs-lock, but to honor file permissions when doing 'svn delete', irrespective of whether svn:needs-lock is set. You're allowed to modify and commit changes to a file that has the svn:needs-lock property regardless of whether it's locked or not. svn:needs-lock is not a constraint, it's just a reminder. I see. I was thinking of it as a constraint, because we had customized our setup to prevent checking in unlocked files in our pre-commit hook script. Unfortunately, this same method can't be used to customize the svn delete behavior, because the local file deletion happens exclusively on the client side. Only at commit time will the user be reminded there is an issue. svn delete is not, and should not be, special. FWIW, I've seen editors that automagically make a file writable if you start modifying it ... I think there would be symmetry between this behavior and how svn currently handles file permissions: svn makes files with svn:needs-lock present read-only if no lock is set, so users that try to edit the file notice it is read-only, and take appropriate action - get the lock. In the same way, if 'svn delete' warned about or refused to delete read-only files, the user would be reminded to get the lock. This behavior is similar to how the unix rm command behaves. It really depends on what you think Unix rm actually is. The unlink() or remove() functions don't care about permissions on the target, only that you have write permission on the parent directory. It does not surprise me to hear that system functions don't care about file permissions. The OS flavor I'm most familiar with is rhel5. Here is how the interactive rm command behaves in this case: $ ll foo.txt -r--r- 1 usb00219 nxp 4 Nov 15 15:42 foo.txt $ rm foo.txt rm: remove write-protected regular file `foo.txt'? y So while rm is perfectly capable of removing the read-only file in a directory where I have write permissions, it politely asks first. I had assumed the rm command behaves similarly on many flavors of Unix (as well as Linux). Given that you can lock a deleted file, I really don't see a problem. If Subversion started prompting the user in such cases, the change in behaviour might break scripts for people who depend on the Unix-like delete behaviour, where file permissions don't matter but directory permissions do. Your last point is hard to refute - it would be change in behavior, and would mess up existing scripting that does not expect interactive prompts. Maybe this behavior can be made optional, enabled via the configuration file? Locking a deleted file will work in the end. It is just a little less intuitive, in my my opinion. Best regards, Rick
Re: svn delete removes read-only files
On 11/15/2013 3:57 PM, Rick Varney wrote: Branko Čibej brane at wandisco.com writes: It really depends on what you think Unix rm actually is. The unlink() or remove() functions don't care about permissions on the target, only that you have write permission on the parent directory. It does not surprise me to hear that system functions don't care about file permissions. The OS flavor I'm most familiar with is rhel5. Here is how the interactive rm command behaves in this case: $ ll foo.txt -r--r- 1 usb00219 nxp 4 Nov 15 15:42 foo.txt $ rm foo.txt rm: remove write-protected regular file `foo.txt'? y So while rm is perfectly capable of removing the read-only file in a directory where I have write permissions, it politely asks first. I had assumed the rm command behaves similarly on many flavors of Unix (as well as Linux). This is probably due to an alias set up in your login script, e.g. .bashrc. Type alias at the command prompt; you will probably find that rm is aliased to rm -i, which prompts before removing files. rm does not prompt like this by default. ll is not a Unix/Linux command either, so it's a pretty safe bet that you have aliases set up, either in the distro you have installed, or configured by your sysadmin (on my CentOS machines, this alias is present only for the root account by default). Try \rm foo.txt (backslash before executable name); I'll bet that it does not ask you for permission to remove a write-protected file. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: svn delete removes read-only files
On 16.11.2013 00:57, Rick Varney wrote: Branko Čibej brane at wandisco.com writes: You're allowed to modify and commit changes to a file that has the svn:needs-lock property regardless of whether it's locked or not. svn:needs-lock is not a constraint, it's just a reminder. I see. I was thinking of it as a constraint, because we had customized our setup to prevent checking in unlocked files in our pre-commit hook script. Sure, you can use a pre-commit hook to prevent committing files without locks; but there's nothing you can do to prevent anyone from editing it, short of using advanced access control in the working copy directories and modifying or otherwise wrapping the Subversion command-line client. Maybe this behavior can be made optional, enabled via the configuration file? Changing client behaviour via config file options is almost always a bad idea ... every such option makes testing more complex and bug triage more time consuming. I'm not saying that there's no chance we'd ever change the way 'svn delete' behaves; I only stated some of the arguments against that, and there can certainly be other opinions. But we'd have to see some indication that the case you describe is actually moderately common. Frankly, I doubt it is; because mandatory locking isn't, in my experience, a very common workflow with Subversion. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
svn delete removes read-only files
Hello, At my company we are using the lock-modify-unlock model, with the svn:needs-lock property set on most files. We have a pre-commit hook that prevents committing unlocked files. We are currently on Subversion 1.6.6. Here is a typical frustrating sequence that happens when removing files: # User deletes file, forgetting to get the lock first. $ svn rm foo.txt D foo.txt # User tries to commit. $ svn ci -m deleted foo.txt Deleting foo.txt svn: Commit failed (details follow): svn: Commit blocked by pre-commit hook (exit code 1) with output: ... # Argh! User tries to lock the deleted file, so commit can proceed. svn lock foo.txt svn: Can't change perms of file '/home/varney/foo.txt': No such file or directory # Curses! Foiled again! # Actually, the user did get the lock, but doesn't realize it, because svn gave an error message. # At this point the user contacts me for help. While I understand why svn behaves this way, it *is* counter-intuitive. Here is my suggestion for a change to how svn delete behaves, to avoid this situation: Modify svn delete so it refuses to remove read-only files. This way, the need to lock becomes more intuitive to users, in the same way locking a file opens up write permissions so a file can be edited. What do you think? Any alternatives I have not considered? Should I open a feature request for this? Best regards, Rick Varney
Re: svn delete removes read-only files
On 14.11.2013 19:24, Rick Varney wrote: Hello, At my company we are using the lock-modify-unlock model, with the svn:needs-lock property set on most files. We have a pre-commit hook that prevents committing unlocked files. We are currently on Subversion 1.6.6. Here is a typical frustrating sequence that happens when removing files: # User deletes file, forgetting to get the lock first. $ svn rm foo.txt D foo.txt # User tries to commit. $ svn ci -m deleted foo.txt Deleting foo.txt svn: Commit failed (details follow): svn: Commit blocked by pre-commit hook (exit code 1) with output: ... # Argh! User tries to lock the deleted file, so commit can proceed. svn lock foo.txt svn: Can't change perms of file '/home/varney/foo.txt': No such file or directory # Curses! Foiled again! # Actually, the user did get the lock, but doesn't realize it, because svn gave an error message. Good catch; this is the actual bug. It's OK to lock a nonexistent path, and if the lock had been acquired on the file's URL instead of the working copy path, it would most likely work without emitting an error. # At this point the user contacts me for help. While I understand why svn behaves this way, it *is* counter-intuitive. Here is my suggestion for a change to how svn delete behaves, to avoid this situation: Modify svn delete so it refuses to remove read-only files. This way, the need to lock becomes more intuitive to users, in the same way locking a file opens up write permissions so a file can be edited. What do you think? Any alternatives I have not considered? Should I open a feature request for this? I disagree with the behaviour change because it makes 'svn delete' in the presence of svn:needs-lock behave exactly opposite to every other command. IMO, it's quite enough to simply fix the bug where we try to change the permissions on a non-existent local path. So I suggest you file a bug for that, not for the behaviour change. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: svn delete removes read-only files
Branko Čibej br...@wandisco.com writes: On 14.11.2013 19:24, Rick Varney wrote: We are currently on Subversion 1.6.6. What do you think? Any alternatives I have not considered? Should I open a feature request for this? I disagree with the behaviour change because it makes 'svn delete' in the presence of svn:needs-lock behave exactly opposite to every other command. IMO, it's quite enough to simply fix the bug where we try to change the permissions on a non-existent local path. So I suggest you file a bug for that, not for the behaviour change. We won't fix this in 1.6 and 1.8 is already fixed: $ svn rm wc/A/f D wc/A/f $ svn st wc/A/f D wc/A/f $ svn lock wc/A/f 'f' locked by user 'pm'. $ svn st wc/A/f DK wc/A/f -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: svn delete removes read-only files
On 14.11.2013 21:44, Philip Martin wrote: Branko Čibej br...@wandisco.com writes: On 14.11.2013 19:24, Rick Varney wrote: We are currently on Subversion 1.6.6. What do you think? Any alternatives I have not considered? Should I open a feature request for this? I disagree with the behaviour change because it makes 'svn delete' in the presence of svn:needs-lock behave exactly opposite to every other command. IMO, it's quite enough to simply fix the bug where we try to change the permissions on a non-existent local path. So I suggest you file a bug for that, not for the behaviour change. We won't fix this in 1.6 and 1.8 is already fixed: $ svn rm wc/A/f D wc/A/f $ svn st wc/A/f D wc/A/f $ svn lock wc/A/f 'f' locked by user 'pm'. $ svn st wc/A/f DK wc/A/f Yes, I was just going to say. I added test cases for this on trunk, and they passed; I've just been running them on 1.8, where they pass as well. In other words, upgrading to 1.8 will fix the issue, and in the meantime, ask your users to either revert the delete first (i.e., 'svn revert file; svn lock file; svn rm file; svn commit', or to use the URL in the 'svn lock' command. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: svn delete removes read-only files
On 14.11.2013 21:54, Branko Čibej wrote: On 14.11.2013 21:44, Philip Martin wrote: Branko Čibej br...@wandisco.com writes: On 14.11.2013 19:24, Rick Varney wrote: We are currently on Subversion 1.6.6. What do you think? Any alternatives I have not considered? Should I open a feature request for this? I disagree with the behaviour change because it makes 'svn delete' in the presence of svn:needs-lock behave exactly opposite to every other command. IMO, it's quite enough to simply fix the bug where we try to change the permissions on a non-existent local path. So I suggest you file a bug for that, not for the behaviour change. We won't fix this in 1.6 and 1.8 is already fixed: $ svn rm wc/A/f D wc/A/f $ svn st wc/A/f D wc/A/f $ svn lock wc/A/f 'f' locked by user 'pm'. $ svn st wc/A/f DK wc/A/f Yes, I was just going to say. I added test cases for this on trunk, and they passed; I've just been running them on 1.8, where they pass as well. In other words, upgrading to 1.8 will fix the issue, and in the meantime, ask your users to either revert the delete first (i.e., 'svn revert file; svn lock file; svn rm file; svn commit', or to use the URL in the 'svn lock' command. And here's the related issue: http://subversion.tigris.org/issues/show_bug.cgi?id=4304 -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
