Bug 206354 - Cannot update filemode for directories
Cannot update filemode for directories
Status: CLOSED DUPLICATE of bug 231498
Product: Red Hat Network
Classification: Red Hat
Component: RHN/Web Site (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Grant Gainey
wes hayutin
: Reopened
Depends On: 231498
Blocks: 229277
  Show dependency treegraph
Reported: 2006-09-13 16:33 EDT by Ken Ganong
Modified: 2007-04-18 13:49 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-20 11:30:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ken Ganong 2006-09-13 16:33:32 EDT
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 17:39:48 EDT
There were problems with directories and binary files.  Updates to fix all three

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 10:06:04 EST
Moving to ON_DEV
Comment 3 Grant Gainey 2006-12-04 17:03:18 EST
ON_QA, here we come!
Comment 4 wes hayutin 2007-01-09 08:50:46 EST
This works.. the file size now is the totoal file size of the sum of revisions
Comment 5 wes hayutin 2007-03-08 13:39:29 EST
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 13:42:19 EST
actually on second thought I think this is a new bug.. so putting this back in

and will open a new bug against 501h
Comment 7 wes hayutin 2007-03-09 14:43:50 EST
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 14:54:43 EDT
moving to must, let's put this one to bed...
Comment 9 Grant Gainey 2007-03-20 11:30:57 EDT
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.