From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
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):
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
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).
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
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
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