Bug 112189 - PublishedFile.delete() incorrectly deletes ALL pubToFS content on Windows
PublishedFile.delete() incorrectly deletes ALL pubToFS content on Windows
Status: CLOSED WONTFIX
Product: Red Hat Enterprise CMS
Classification: Retired
Component: other (Show other bugs)
6.0
All Linux
medium Severity high
: ---
: ---
Assigned To: ccm-bugs-list
Jon Orris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-15 15:41 EST by Mike Bonnet
Modified: 2007-04-18 13:00 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-05 13:57:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Replace backslashes with forward-slashes in filesystem path before comparing to path stored in the database (2.82 KB, patch)
2003-12-16 11:36 EST, Mike Bonnet
no flags Details | Diff
occurrences of "/", '/', and java.io.File.separator (32.22 KB, text/plain)
2003-12-23 11:03 EST, Vadim Nasardinov
no flags Details

  None (edit)
Description Mike Bonnet 2003-12-15 15:41:29 EST
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).
Comment 1 Mike Bonnet 2003-12-15 18:34:45 EST
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.
Comment 2 Mike Bonnet 2003-12-16 11:36:37 EST
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.
Comment 3 Richard Li 2003-12-23 10:00:08 EST
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, '/');

?

Comment 4 Vadim Nasardinov 2003-12-23 10:33:27 EST
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.
Comment 5 Vadim Nasardinov 2003-12-23 11:03:06 EST
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.
Comment 6 Jon Orris 2006-09-05 13:57:39 EDT
Closing old tickets



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