Bug 112189
| Summary: | PublishedFile.delete() incorrectly deletes ALL pubToFS content on Windows | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Enterprise CMS | Reporter: | Mike Bonnet <mikeb> | ||||||
| Component: | other | Assignee: | ccm-bugs-list | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Jon Orris <jorris> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 6.0 | CC: | richardl | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2006-09-05 17:57:39 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Sorry, let me clarify that statement about data loss. This bug does not cause any permanent loss of data (everything is still in the database). However, if pubToFS is being used to generate static HTML for a live site, then content will disappear from the live site unexpectedly, and it will appear to users that data is missing. Also, there is no way to restore that data to the live site, since republishing any already-live content requires an unpublish first, and since unpublishing triggers the deletion of all currently published content. Created attachment 96558 [details]
Replace backslashes with forward-slashes in filesystem path before comparing to path stored in the database
Tested successfully on Windows in WebSphere 5.
Bug 112576 points out the existence of java.io.File.separator. Perhaps a better implementation would be something like: filePath = filePath.replace(java.io.File.separator, '/'); ? We store paths in the database. Do we want the stored path format to be platform-dependent? If yes, then it means it would be harder for users to switch from a Unix-hosted servlet container to a Windows-hosted one, or vice versa. If no, then we have to pick either forward slash or backslash as a separator for paths stored in the database. Created attachment 96680 [details]
occurrences of "/", '/', and java.io.File.separator
Looking at Core+CMS, we have about 250 occurrences of the literal string
"/", 44 occurrences of the literal char '/', and 9 occurrences of
java.io.File.separator. That's a lot of code to audit.
Closing old tickets |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031202 Galeon/1.3.10 Description of problem: PublishedFile.delete() has code to handle deleting empty directories when the last item in a directory is unpublished. The way it checks if a directory is empty is to query the number PublishedFile objects whose path starts with the path of the directory in question. The path stored in the PublishedFile object is based on the output of ContentItem.getPath(), so it is always forward-slash separated. However, the path it is compared to is the result of calling java.util.File.getPath(), and is platform-dependent. On *nix, file system paths are also forward-slash separated, so the comparison works as expected. However, on Windows, File.getPath() returns a backslash-separated path. This means that no PublishedFile objects ever match the file system directory path, and the directory (and all contents) are deleted. The same comparison is then performed on the parent of the deleted directory, which is also then deleted, all the way up to the pubToFS root directory. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Publish several content items using pubToFS 2. Unpublish one of them. Actual Results: All pubToFS content is gone. Expected Results: Only the single item that was unpublished should be gone. Additional info: It looks like a quick fix would be to replace all back-slashes with forward-slashes in the directory path we're comparing against. I'm going to experiment with this, and I'll post a patch if it works. However, pubToFS should probably be audited for other *nix-isms like this. Marking as high, since this is really a data-loss bug (published content getting deleted), and there is no simple work-around (other than never unpublishing or republishing anything, which is not really a reasonable thing to do).