patchConcurrent Versions System - Patches: patch #4446, Set execute bits on file via `cvs...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

patch #4446: Set execute bits on file via `cvs admin'

Submitter:  Derek Robert Price <dprice>
Submitted:  Mon 19 Sep 2005 07:06:46 PM UTC
   
 
Category:  None Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  mdb Open/Closed:  Closed
Fixed Release:  None Fixed Feature Release:  1.12.14

Jump to the original submission

Sat 12 Nov 2005 08:35:02 PM UTC, comment #13: 

The change for admin.c and parseinfo.c has been committed along
with a slight variation of the sanity.sh and cvs.texinfo patch
to the FEATURE branch.

Mark D. Baushke <mdb>
Group administrator
Sat 05 Nov 2005 11:52:13 PM UTC, comment #12: 

Attaching a stab at documenting these new options.
Please review.
Also on the code diff, I noticed that repository is
misstyped as respoitory. Also maybe --execute should be listed before --no-execute when you do cvs -H admin.

Thanks,
Alex

Alex Manoussakis <amanou>
Sat 05 Nov 2005 06:09:48 AM UTC, comment #11: 

I added 2 simple tests (--execute/--no-execute).
I squeezed them between existing tests under modes, (where it made sense to me) so I had to renumber modes-8 and up.
Hope that's ok ...
The tests pass after my revision of the admin.c patch.
Attached is the diff against the head branch of sanity.sh
Please let me know if the diff looks ok.

Thanks,
Alex

Alex Manoussakis <amanou>
Sat 05 Nov 2005 05:23:37 AM UTC, comment #10: 

Submitted revised patch, with the umask taken out.
The execute bits now are just combined with the file's existing permissions. The behavior of --execute / --no-execute won't be affected by the umask anymore.

Alex

Alex Manoussakis <amanou>
Sat 05 Nov 2005 04:53:37 AM UTC, comment #9: 

While I was trying to add some tests for --execute,
I discovered that the user's umask created strange results.
With umask 022 I had no issues but when my umask was 077
--execute changed the file's permissions
from -r--r--r-- to -r-xr--r--
A subsequent --execute would change the permissions to -r--------
The user's umask shouldn't matter to what happens on the server.
It's good enough (in fact it's great) that the patch applies the execute bit wherever the file's owner/group/other has the read bit set.

Alex

Alex Manoussakis <amanou>
Fri 04 Nov 2005 07:19:27 PM UTC, comment #8: 

One more revision, to print warnings for unrecognized long options in UserAdminOptions and to fix a bug in the search routine.  Still needs tests & doc.

Derek Robert Price <dprice>
Group administrator
Fri 04 Nov 2005 03:14:04 PM UTC, comment #7: 

Based on some private comments from Mark Baushke, I've added a change to carry through my enum change and forward the --execute arguments through to the server.  This still needs tests and docs...

Derek Robert Price <dprice>
Group administrator
Thu 03 Nov 2005 11:02:40 PM UTC, comment #6: 

How about the untested attached patch?  It allows semicolon delimited long-options in config.  There is little error checking though - I enabled trace for use in debugging, but this is a security issue.  It might be better to force a shortopt[;longopt...] format so that mispelled longopts cause errors or warnings rather than being interpreted as short options.

This will also need doc and tests to go in...

Derek Robert Price <dprice>
Group administrator
Thu 03 Nov 2005 08:48:43 PM UTC, comment #5: 

I have updated the patch to use --no-execute and --execute.
I am less clear on how to update UserAdminOptions for this.
So, for now I guess only the administrator will be able to
use these new options. I have not written any sanity.sh
tests. Are we able to assume that test -x is portable yet
(there are comments about BSD 4.3 not supporting it)?

Mark D. Baushke <mdb>
Group administrator
Thu 03 Nov 2005 07:07:43 PM UTC, comment #4: 

Attached Mark's patch from 2004-12-08, as requested.

One quick comment, changing admin.c to accept long options should be trivial (only two or three lines need be cut & pasted from main.c and tweaked, IIRC).  If this goes in, I would much rather see eXtensions added as long options rather than arguments to -X.  Using arguments to -X would only confuse users when the intention, as near as I can tell, appears simply to be to enable long options (http://lists.gnu.org/archive/html/bug-cvs/2004-12/msg00075.html).

Derek Robert Price <dprice>
Group administrator
Thu 03 Nov 2005 05:56:07 PM UTC, comment #3: 

I think the patch is one included in this message:
http://lists.gnu.org/archive/html/bug-cvs/2004-12/msg00079.html

If so, please add it back here as patch #4446
Thanks,
Alex

Alex Manoussakis <amanou>
Thu 03 Nov 2005 03:45:00 PM UTC, comment #2: 

Possibly.  Was there a patch attached to the original issue?  I may have missed that when I moved the issue from cvshome.org.  Unfortunately, cvshome.org is gone now, so we can no longer get it that way.  Do you still have the patch?

Regards,

Anonymous
Wed 02 Nov 2005 08:10:40 PM UTC, comment #1: 

Hmm, shouldn't a patch be attached as a file here?

Alex

Alex Manoussakis <amanou>
Mon 19 Sep 2005 07:06:46 PM UTC, original submission:  

- Desire the ability to deal with execute bits between
    'cvs rm' and a new 'cvs add' of the same filename.
    Possibly a new admin command to change the execute bits
    on the repository file?
    https://ccvs.cvshome.org/issues/show_bug.cgi?id=115


From https://ccvs.cvshome.org/issues/show_bug.cgi?id=115:

I'm using cvs in client-server mode.
When I first "cvs add" a file, if the file is
executable, the server stores it as such,
otherwise is stores it without execute permissions
and subsequent checkout of that file will have
the execute bit set accordingly on the client.
So far so good.
The problem is, that if a file is initially added
while having wrong permissions, those permissions
are stuck forever, and there's no way to correct
them from the client side. Even "cvs delete" and
subsequent "cvs add" of the file with the
executable bit changed has no effect, because the
initial permissions are preserved in the Attic
and are duplicated when the file is re-added.
The enhancement I'm asking for is the following:
When a previously deleted file is "cvs add"ded,
please don't preserve the execute permissions of
the old file in the Attic, but instead apply
whatever the -x/+x permissions of the newly added
file are.
Note that I'm talking about the classic behavior
of cvs regarding the executableness of added
files, nothing to do with the PreservePermissions
feature which doesn't work on client-server
anyway.
Thank you!



------- Additional comments from Alex Manousakis Thu Apr 8 17:04:49 -0700 2004 -------

Any chance this issue can be accepted ? It's been UNCONFIRMED for 1 year

Thank you,
Alex



------- Additional comments from Mark D. Baushke Thu Apr 8 17:13:34 -0700 2004 -------

If you were to checkout the original version of the file
after having done a 'cvs delete' and a 'cvs add' to revive
it, you would see the same permission bits as were on the
original version of the file. This is not a bad thing.

I suppose it might make sense for users to be able to
change the execute bit attributes on the repository file
just as they are able to change the keyword expansion
settings... via the 'cvs admin' command.

A patch to modify the permission bits on the file via
a 'cvs admin' command would be greatfully accepted.

Derek Robert Price <dprice>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #6907:  cvs.texinfo-x-200511051.diff added by amanou (2KiB - text/plain - Documentation for admin --execute / --no-execute)
file #6905:  sanity-x-200511041.diff added by amanou (4KiB - text/plain - Added admin --execute/--no-execute tests)
file #7001:  admin-x-200511043.diff added by amanou (7KiB - text/plain - Revised previous patch (don't apply the umask anymore))
file #7057:  admin-x-200511042.diff added by dprice (7KiB - application/octet-stream - Fix bugs & add warnings, re discussion with Mark.)
file #7056:  admin-x-200511041.diff added by dprice (6KiB - application/octet-stream - Revised previous patch according to Mark's suggestions.)
file #7051:  admin-x-longopts-w-config.diff added by dprice (6KiB - application/octet-stream - Add long option handling to parse_config.)
file #7050:  admin-x-longopt.diff added by mdb (4KiB - text/x-patch - Patch for long options --execute and --no-execute)
file #7049:  admin-x.diff added by dprice (5KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 15 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-11-12 mdb Open/ClosedOpen Closed
    Fixed Feature ReleaseNone 1.12.14
2005-11-12 mdb StatusNone Done
    Assigned toNone mdb
2005-11-05 amanou Attached File- Added cvs.texinfo-x-200511051.diff, #5442
2005-11-05 amanou Attached File- Added sanity-x-200511041.diff, #5440
2005-11-05 amanou Attached File- Added admin-x-200511043.diff, #5438
2005-11-04 dprice Attached File- Added admin-x-200511042.diff, #5434
2005-11-04 dprice Attached File- Added admin-x-200511041.diff, #5433
2005-11-03 dprice Attached File- Added admin-x-longopts-w-config.diff, #5428
2005-11-03 mdb Attached File- Added admin-x-longopt.diff, #5427
2005-11-03 dprice Attached File- Added admin-x.diff, #5426
2005-11-02 amanou Carbon-Copy- Added amanou
2005-09-19 dprice Carbon-Copy- Added -email is unavailable-
    Carbon-Copy- Added -email is unavailable-

Back to the top

Powered by Savane 3.13-f8d8.
Corresponding source code