Bug 206354 - Cannot update filemode for directories
Summary: Cannot update filemode for directories
Keywords:
Status: CLOSED DUPLICATE of bug 231498
Alias: None
Product: Red Hat Network
Classification: Retired
Component: RHN/Web Site
Version: rhn420
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Grant Gainey
QA Contact: wes hayutin
URL:
Whiteboard:
Depends On: 231498
Blocks: 229277
TreeView+ depends on / blocked
 
Reported: 2006-09-13 20:33 UTC by Ken Ganong
Modified: 2007-04-18 17:49 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-03-20 15:30:57 UTC
Embargoed:


Attachments (Terms of Use)

Description Ken Ganong 2006-09-13 20:33:32 UTC
When attempting to create a new revision of a directory (by changing the
permissions of that directory), the page generates a 500 error.

It tries to update the config revision's delim start and delim end to null.

Comment 1 Grant Gainey 2006-09-28 21:39:48 UTC
There were problems with directories and binary files.  Updates to fix all three
problems.

Test plan:
- Create a directory
- Then, change its mode and choose "update revision"

- Create a binary file of size 'n'
- Change its mode and choose "Update Revision".  Note that there should now be
2*n "total bytes"


Comment 2 Grant Gainey 2006-11-06 15:06:04 UTC
Moving to ON_DEV

Comment 3 Grant Gainey 2006-12-04 22:03:18 UTC
ON_QA, here we come!

Comment 4 wes hayutin 2007-01-09 13:50:46 UTC
This works.. the file size now is the totoal file size of the sum of revisions

Comment 5 wes hayutin 2007-03-08 18:39:29 UTC
This is no longer working correctly...
after changing the mode on a directory.. and then create a new revision...
you get an error..

    * Macro end tag is required.
    * Macro start tag is required.

Comment 6 wes hayutin 2007-03-08 18:42:19 UTC
actually on second thought I think this is a new bug.. so putting this back in
verified...

and will open a new bug against 501h

Comment 7 wes hayutin 2007-03-09 19:43:50 UTC
ok.. cant really test this because of the above new bug... the error will have
to be tracked in the 501h bug..

Comment 8 Bret McMillan 2007-03-16 18:54:43 UTC
moving to must, let's put this one to bed...

Comment 9 Grant Gainey 2007-03-20 15:30:57 UTC
The base bug identified originally was fixed and verified - but the behavior in
231498 now gets in the way of finalizing the process.

I'm going to mark this bug as a dup, and fix it in 231498.

*** This bug has been marked as a duplicate of 231498 ***


Note You need to log in before you can comment on or make changes to this bug.