1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in

Ticket #11244 (closed: fixed)

Opened 4 years ago

Last modified 3 years ago

FRS: release notes association malfunction

Reported by: keithmarshall Owned by: hinojosa
Keywords: ENGR AT-63 Cc: mingw-dvlpr@…
Private: no


If a package is moved, within the FRS hierarchy as viewed in the browser based File Manager, release notes associations to a file in the same logical package directory are not updated. For example, the MinGW project has a package "MinGW mpc/mpc-0.8.1-1", which includes the file "mpc-0.8.1-1-mingw32.RELEASE_NOTES.txt"; this is intended to be associated, as the applicable release notes, with all other files in this package.

When the maintainer of this package originally uploaded it, he did so as the pre-release package "MinGW Proposed/mpc-0.8.1-1", then subsequently moved to its released FRS location at "MinGW mpc/mpc-0.8.1-1"; however, the release notes association, as presented in the "files" view at "https://sourceforge.net/projects/mingw/files" continues to point to "MinGW Proposed/mpc-0.8.1-1/mpc-0.8.1-1-mingw32.RELEASE_NOTES.txt". Of course, this path is no longer valid, and any attempt to access the release notes for this package, via the "files" view "release notes" link icon, is doomed to fail.

I have tried deleting the existing release notes association for this package, (including removal of the release notes attribute from the associated file), then reassigning it entirely from scratch, but to no avail; the linked association remains stubbornly tied to the defunct path.

Change History

Changed 4 years ago by ctsai

  • owner set to ctsai
  • status changed from new to assigned

Changed 4 years ago by ctsai

  • keywords PEND added


I just tested this on one of my projects and this is what I found (please confirm if this is the same behavior you're seeing).

I followed these steps:

  1. I marked a file within a folder as a release note (dir1/subdir1/rel_note1).
  2. I set dir1/subdir1/rel_note1 as the release note for the dir1/subdir1 directory.
  3. I moved (cut/paste) subdir1 to dir2.
    • at this point, the /files page still showed the release note pointing to dir1/subdir1/rel_note1.
    • however within the file manager, the paths in the release note dropdown was updated to dir2/subdir1/rel_note1 and
    • the release note selection for dir2/subdir1 was unselected.
  4. Then, I set dir2/subdir1/rel_note1 as the release note for dir2/subdir1
    • at this point, the release note on the /files page was updated properly.

So, the main bug as I see it in this excercise is that the /files page does not properly unset the release note when it's moved within the file manager. However, once it's set again for that file/directory, it's corrected.

Please give that a shot and let me know if your findings match up with mine.

Chris Tsai, SourceForge.net Support

Changed 4 years ago by keithmarshall

No, I CANNOT reproduce ANYTHING like what you appear to see! There seems to be NOTHING I can do, to make the "files" view forget that original release notes association, with the release note file expected within the "MinGW Proposed/mpc-0.8.1-1" path.

Yes, when I drop the release note attribute from the file, it disappears from the drop down list of assignable release note files. I did that, then moved the entire mpc-0.8.1-1 subdirectory back into "MinGW Proposed", and with the file still not marked with the release note attribute, the "files" view showed only a PARTIAL move of the contained files, (which is clearly ANOTHER BUG -- the "File Manager" showed EVERYTHING as moved), but all files in BOTH locations CONTINUED to show a release note in the "MinGW Proposed" tree!

I then moved everything back again, reset the release note attribute for the file, which made it reappear in the drop down, but I can't tell what its path is, because that is elided, and only the actual file name is visible. I then DELETED the (now empty) "MinGW Proposed" directory, BEFORE reassigning the release note to the correctly positioned mpc-0.8.1-1 directory, but no joy; the "files" view STILL insists that the release note lives in the non-existent "MinGW Proposed" path!

This is broken, BIG TIME, and there seems to be nothing I can do to get around the breakage; back to you, I think.

Changed 4 years ago by ctsai

  • keywords ENGR SFX-1110 added; PEND removed
  • owner changed from ctsai to hinojosa


I just tried my steps again, and it worked just like I outlined. However, since this is not working for you, I'm escalating this issue to our engineering team for further review.

Chris Tsai, SourceForge.net Support

Changed 4 years ago by keithmarshall

Perhaps the total length of the path name is significant?

FTR, I did just succeed in reassigning one such problematic release note, after relocation of its container directory, from:

/MSYS Base System/msys-1.0.14-1/msysCORE-1.0.14-1-msys-1.0.14.RELEASE_NOTES.txt



by adopting the following ungainly, time-consuming and ultimately unacceptable procedure:

  1. Create the new (empty) /MSYS directory in "File Manager"
  2. Cut the "/MSYS Base System" directory from "File Manager" top level
  3. Paste into /MSYS
  4. Rename pasted directory to "BaseSystem"
  5. Open "All Files" view from project page
  6. Observe successful directory relocation, but note reference still to old path.
  7. Return to "File Manager"
  8. Drop "release note" attribute for .RELEASE_NOTES.txt file
  9. Cut .RELEASE_NOTES.txt file
  10. Paste into /MSYS directory
  11. Reassign "release note" attribute on pasted file
  12. Assign pasted file as release note for /MSYS/BaseSystem/msys-1.0.14-1 directory
  13. Reload "All Files" view
  14. Observe (now correctly) updated release note assignment.
  15. Return to "File Manager"
  16. Drop "release note" assignment again
  17. Cut .RELEASE_NOTES.txt file from /MSYS
  18. Paste back into /MSYS/BaseSystem/msys-1.0.14-1
  19. Reassign "release note" attribute
  20. Reassign as release note for container directory
  21. Reload "All Files" view
  22. Observe release note now correctly associated

That said, even this procedure seems to be rather hit and miss. Repeating it for the "MinGW mpc" case originally reported still failed to correct the broken association. I eventually did manage to correct this, after deleting its original .RELEASE_NOTES.txt file, uploading anew, and then moving things around several more times; (even after the delete and fresh upload, the "All Files" view still seemed to refuse to forget the original defunct association). Althogether, NOT a pleasant user experience.

Changed 4 years ago by keithmarshall

Spoke too soon. While the association now appears to be correct for the freshly uploaded file, all other files in the directory continue to show the defunct reference to the non-existent path.

Changed 4 years ago by hinojosa

Thank you for the feedback. We have added this information to the engineering team.

Changed 4 years ago by hinojosa

  • status changed from assigned to closed
  • resolution set to wontfix

Hello Keith,

The engineering team has reviewed this issue and at this time is opting to not fix this. I expect that there are changes for the system overall that will make this feature moot.

Best regards,

Daniel Hinojosa - Sr. Manager, SourceForge.net Support

P.S., Be sure to monitor our Site Status.

Changed 4 years ago by keithmarshall

Okay. If "downloads" is the future, then this likely will cease to be a problem. However, I do note that "downloads" currently appears to offer no facility for viewing release notes in the browser. This is a feature we've had for as long as I can remember. I sincerely hope that you have some plan to re-implement it; to simply discard it after so long would seem to be a most undesirable regression.

Changed 4 years ago by hinojosa

  • keywords AT-63 added; SFX-1110 removed
  • status changed from closed to reopened
  • resolution wontfix deleted


I worked with our engineering team on this. They have agreed to take this back up and are working towards a plan for release notes. At this point, as it sounds like a re-engineering effort, I'll have to wait to hear from them on what that looks like going forward.

All-in-all, good news as this moved from won't fix to, working on it.

Best regards,

Daniel Hinojosa - Sr. Manager, SourceForge.net Support

Changed 3 years ago by ctsai

  • status changed from reopened to closed
  • resolution set to fixed


Okay, so the readme functionality has replaced the old release notes functionality. This bug no longer applies.

Chris Tsai, SourceForge.net Support

Note: See TracTickets for help on using tickets.