Using "Files not in database" I recognized a bunch of files which lost connection to there nodes (images and attached files).
Now I am looking for some way to reattach them (deletion is not the way I prefer).
If you agree with this proposal and need some help I will try to support this feature.

regards
Schildi

CommentFileSizeAuthor
#7 auditfiles.patch29.2 KBmikeryan
#5 drupal-files.png146.68 KBschildi

Comments

Stuart Greenfield’s picture

Status: Active » Postponed

I like this idea and have thought about it before, but audit files isn't getting much of my attention at the moment.

I'll try to get round to doing something on this at some point, but not sure when!

reb00tz’s picture

Version: 5.x-1.0 » 5.x-2.0

+1 to this request. This is currently high on my priority, and will try to see if I can contribute anything in terms of code. The reason for this is that there is a _huge_ bug in the Drupal blogapi that uploads images and attachments as part of blog publishing - but does _not_ populate the "files" table.

The way I see myself doing this is doing a foreach() search for the file name (escaped to match) in the contents of every row in the "node_revision" table (with a "limit of 1") and populate the "files" table.

schildi’s picture

Good idea using the node_revisions table.
My proposal is to do it not completely automatic but create an additional field for each file listed on page "not in database". This field is editable but will be initiated by some process with the assumed nid it belongs to.

reb00tz’s picture

Good point on the editable field - it would make manual corrections much easier.

Meanwhile, had a really bad time trying to track through the Drupal code (this is the first time I've delved into Drupal code), going on a merry-go-round through blogapi.module, upload.module, image.module, file.module, image_assist.module, node.module and everything in between trying to see where the "files" table insertion code came from (eventually found in the image.module)...

Therein lies an "issue" though; from a "narrow" point of view in regards to "Image" nodes, there appears to be different "types" in the "files" table ("_original", "thumbnail", "preview") - and these "type" names are actually stored in the "files" table.

From a simple search in attempting to manually clean up my own "files" table, it appears that some of these "thumbnail" files are larger in size than the original - so file size is _not_ the way to differentiate originals from thumbnails from previews. This may not be an issue as I have seen a "rebuild" function in the image.module - so as long as there are originals (and we can identify them), it should be something we can work around.

schildi’s picture

StatusFileSize
new146.68 KB

Yes, the image module uses "filename" in table files and "description" in file_revisions to distinguish between "_original", "preview" and "thumbnail".
And, as far as I remember table file_revision is populated when the corresponding node (table node) was edited. That means, vid in file_revisions and in node-revisions are in sync (OK, not each vid in node_revisions has a corresponding value in file_revision because of different node-types).

Please have a look at the attached image.

mikeryan’s picture

Status: Postponed » Needs work

I did this and more, I was reminded today that I never got around to contributing it. Attached is a massive patch against HEAD, with is Drupal 6-compatible - there's no branch for 6 yet so the Version on this issue doesn't reflect the contents of the patch.

"needs work" because it doesn't scale - the reports need to be paged. But hopefully this can be helpful to people, and maybe someone can refine it.

mikeryan’s picture

StatusFileSize
new29.2 KB

Helps to attach the patch...

mikeryan’s picture

Version: 5.x-2.0 » 6.x-3.x-dev

OK, I've created two branches, 6.x-2.x which is functionally equivalent to 5.x-2.x (safest way for existing users to upgraade), and 6.x-3.x for development of these new features.

reb00tz’s picture

Category: feature » task

Hi mikeryan,

Thanks for the hard work on this - tried installing it, and it appears that the patch doesn't contain any updates for the auditfiles.install, references.admin.inc and unreferenced.admin.inc files...

Haven't tried any functionality as yet though.

moshe weitzman’s picture

Status: Needs work » Fixed

Was committed ages ago

Status: Fixed » Closed (fixed)

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