The files in .svn directory are enumerated as resources by 409-01.ps . This causes 2 problems: - The test file reports a failure. - The file enumeration order was different that resulted in the difference in stdout and raster files. Although this is not an error in Ghostscript, ignoring .svn directory in Ghostscript during the directory enumeration seems to be much easier than moving it out of the way in every test script.
Created attachment 2056 [details] patch Log message: Ignore .svn directory during directory enumeration because it is created in every directory managed by Subversion and it interferes with the resource enumeration. The patch is testing now.
There's no differences in the regression testing because it does 'make install'. When Ghostscript is run with the resources that have .svn directories there are progressions in 215-01.ps and 409-01.ps .
Two comments. Running the file myself, the error reported is: "409-01", "CMap", "If any instances exist, verify their entries." Fail: (/vn/prop-base try) Fail: (/vn/text-base try) Fail: (/vn/format try) Fail: (/vn/README.txt try) Fail: (/vn/empty-file try) Fail: (/vn/entries try) Fail: (/vn/tmp try) Fail: (/vn/wcprops try) Fail: (/.svn try) Fail: (/vn/props try) Trying /.svn is likely to fail because this is a directory not a file, but the others look like the path is getting mangled. Just ignoring paths starting with .svn will shadow this bug. Second, this is really a symptom of a bug in the unix file enumeration; it returns directory names as if they were files. The PLRM doesn't describe the exact behaviour, but IIRC to conform to distiller we should (a) not return directory names, only files and (b) recurse into subdirectories. I believe the Windows implementation of the file enumeration logic does (a) but not (b).
I really DON"T like this patch approach. Instead, we need to either: 1) ignore ANY directories found (platform specific) -or better- 2) recurse into all directories returning only files (leaves of the tree) not bare directory names. The approach (2) is already listed as a bug 688853. We may want recursion selectable since when enumerating Resources categories, we don't want to see any recursion. Approach (1) will avoid problems with 409-01.ps and potential problems with resourceforall enumeration.
The approach 2 will cause the same errors in 409-01.ps unless .svn is ignored.
The related bug is 686853, not 688853.
During the support call, we decided that the best resolution is #1, to make it not recurse into directories. The windows version already _almost_ does this, but the test for FILE_ATTRIBUTE_DIRECTORY is failing because it's an equality test, which gives an undesirable answer when other flag bits (such as hidden) are set. That can be fixed easily. The bountiable aspect of this bug is to make gp_unifs behavior consistent with gp_ntfs. I believe that checking stat() and skipping if the directory attribute is set will do the trick. At the same time, it would be great to fix bug 686853, which is related.
*** Bug 688732 has been marked as a duplicate of this bug. ***
raise the priority since ghostscrpt no longer runs.
leo, as regards this bug, please revert the patch that triggers this in normal runs and post a reference so it can be re-applied when the issue is fixed. Currently those of us on unix can't use trunk.
I committed a temporary workaround with the patch http://ghostscript.com/pipermail/gs-cvs/2006-June/006598.html From my old experience, the best way to resolve it is to recurse subdirectories in filenameforall, and skip ones which are not real files. Subdirectories apper when a resource hane contains '/' - suc names are widely ised in fonts, which may appear in Resource/Font . Note the problem doesn't appear on Windows, because the Windows specific module is more advanced.
I meant "resource name contains '/' - such names are widely used in fonts".
The wrong resource names mentioned in comment #3 could come from bug 688737 "'resourceforall' truncates names of file-based resources".
Created attachment 2283 [details] Fix to filenameforall for unix - do not return directories Is this what you were after?
Micksa, it seems no one noticed your patch when you put it in. Are you still interested in working on this? I'd suggest, based on reading this again, and the related bug 686853, that the proper fix is to: (a) Make the current enumeration code skip directories as per your patch. (b) Make this behaviour selectable at run time, with no recursion by default. (c) Add a boolean to gp_enumerate_files_init to request recursion, and hook it up the the run time switch. (d) Ignore files and directories that begin with '.' in the unix implementation.
Dropping the priority, since this is not affecting customers.
I think we need to port the functionality of gp_enumerate_files_* from gp_ntfs.c to other platforms.
Created attachment 5544 [details] bugs686853-688565.patch Proposed patch. - recursion control parameter for file enumeration functions (only relevant to unix implementation since other platforms doesn't currently implements recursive directory traversal anyway); - filter out directories from enumeration list for unix, ntfs, dos platforms (OS/2 and VMS untested yet); - ignores any file/directory names starting with dot '.' on unix platform; - "RECURSE" dictionary name controls recursion for "filenameforall" (-dRECURSE enables recursion which is now disabled by default); - "-r" command line option enables recursion (old behaviour) for mkromfs utility.
Assign back to reporter for further processing/decision.