Module "swish" uses a "tmp" directory located in the "files" directory und fills it with a huge number of temporary files.
As a result the page showing files "Not in DB" stays blank.
To correct this I put a "tmp" in the following command to avoid the tmp directory from being scanned:
Line 266-267:
// Exclude files in the color folder and .htaccess as we don't need to know about these
if ( !preg_match('@'.preg_quote(file_create_path('color')).'|\.htaccess|tmp@', $file) ) {

Regards
Schildi

Comments

Stuart Greenfield’s picture

Stuart Greenfield commented

I have a plan to make the exclusion filter configurable, so users can exclude whichever files they don't need to know about!

Stuart Greenfield’s picture

Stuart Greenfield commented
Status: Active » Fixed

I have uploaded a test version of a revised audit module to HEAD. This makes the exclusion list configurable from Administer > Site configuration > Audit files.

You can choose to exclude files, paths and extensions.

I've given this some limited testing on my test server, and it seems to be behaving / working as expected, but I'll not release it as an official release until it's had some more testing!

schildi’s picture

schildi commented

Thanks a lot!

that solved the problem for me.
May be you include some hint in "help" or the INSTALL.txt that in case the screen turns blank
* there are to many files to list
* that possibly one or more directories containing temporary files have to be configured

Regards
Schildi

schildi’s picture

schildi commented

Get a "Page not found" for each link in "Audit of files not in the database".
The links look like "http://archiv.bgv-rhein-berg.de/system/files/GeschichteLokal.jpg"
but http://archiv.bgv-rhein-berg.de/files/GeschichteLokal.jpg works.

Regards
Schildi

Stuart Greenfield’s picture

Stuart Greenfield commented
Assigned: Unassigned » Stuart Greenfield
Status: Fixed » Active

Oops!

I've seen something like this before, and off-hand I can't remember what I did to cause it / fix it. I'll have to do some research... At least the bug only affects the new feature..??!!

Sorry about that!

Stuart Greenfield’s picture

Stuart Greenfield commented
Status: Active » Needs review

I am guessing you are using private file transfers. I didn't realise but when that setting is on Drupal checks that the file exists in the database before providing the download. Seeing as we don't have a database entry Drupal thinks it is a bad request and sends you to page not found.

I have updated the DRUPAL-5 branch with a bugfix that writes public urls all the time. That's not a problem as users must have the appropriate access to get to the pages that show the public links.

If you could test the new version, and if it's ok I'll make a new release.

Note to self - remember to test public and private transfer settings in future!!

schildi’s picture

schildi commented

yes , I am using private file transfers. But I don't know what you really mean.
Drupal checks if the file (path) requested exists in the DB. And for some reason I don't know
the Path must now contain this "system" component. Probably I know not enough about Drupals
handling of private versus public files.

I will check your new version tomorrow (it's now about 2:10 h).

Regards
Schildi

Stuart Greenfield’s picture

Stuart Greenfield commented

As I understand it, if you use public transfer then Drupal provides a straight link to the file you request and your webserver handles the request.

If you are using private transfer then Drupal prepends 'system', and Drupal sends the file in place of the webserver. That way Drupal can limit who has access to the file etc. As an additional measure it seems that Drupal also checks the requested file (the bit after /system/) actually exists in the file table.

The audit is those files NOT in the file table, so the request always fails if done privately.

The fix goes back to your original approach and outputs a public link.

That'll teach me to try and be clever and use a built in Drupal function ;-)

[0220 here - our little girl doesn't want to sleep tonight, but as a result I've got 75% of Audit Files ported to Drupal 6 as a practice for moving flashnode and mailsave!)

Stuart Greenfield’s picture

Stuart Greenfield commented
Status: Needs review » Fixed

No further posts to say if the new code did (or didn't work), so assuming that it did and the new code is committed as official release 5.x-2.0 (some new features from version 6 ported to this version, hence major revision level increased).

Setting status to fixed. Please raise new issues with the 5.2 release on a new thread.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.