Greetings!

First, I want to say that Acidfree is an OUTSTANDING module, one of the best I've ever seen for Drupal. I am deeply grateful for its availability. That's why I waited to report this bug until I could contribute a patch with it, to "give something back." :-)

I recently migrated several of my Drupal 4.7.x sites with Acidfree from a server using xfs filesystems to one using ext3 (both under Linux o.s.). On the xfs system, the PHP directory read automatically sorts the files by name, and Acidfree works correctly. However, ext3 presents the directory entries to PHP in an internal hash or inode order, effectively unsorted, which causes Acidfree to create the nodes out of order. The order appears random at first glance, but it is repeatable which is what led me to the solution.

What was needed was just to add a few lines to acidfree.module so that it reads the directory list into an array, then sorts the array, then processes the names in a for-loop, rather than directly processing each name as it is encountered from the directory.

I've attached a patch which works with version 1.62.2.60 of acidfree.module, which is the latest version from CVS branch DRUPAL-4-7 as of today. I intend to port this patch to 5.0 (after first testing to see if it's needed), but wanted to go ahead and get the 4.7 version to you in the meantime.

Please feel free to contact me if I can be of further assistance, and again thanks for a fantastic module!

Syscrusher

Comments

syscrusher’s picture

StatusFileSize
new1012 bytes

Oops....sorry, left an extraneous comment in that patch. Here it is again, cleaned up. Same code, though.

vhmauery’s picture

Status: Needs review » Needs work

this is a duplicate of http://drupal.org/node/37456

I am very tempted to close this. But since I understand the frustration, I will keep it open. I don't want my images sorted in alphabetical order. If anything, I want them sorted by ctime. Change the patch so you can sort the files in various ways, create a setting in the Acidfree settings page and send me that patch.

syscrusher’s picture

Assigned: Unassigned » syscrusher

Sorting by ctime would be fine with me, if it worked. There are problems with this, though. Since ctime only tracks down to one-second precision, it is possible for multiple files to have identical ctime on a fast system. Then the import order becomes indeterminate. Also, when you upload the files, the ctime is based on the upload order rather than the internal Exif timestamp in most situations -- and if your network is fast enough (and files small enough) to do more than one per second, you have the problem of non-unique ctime again.

For most digital cameras and most scanning programs that sequentially number the files they create, the ordering by filename will correspond to ordering by ctime. I do realize, however, that this is not always the case and that there are lots of other places from which one might obtain images, and so I agree with you that sort-by-filename is not universally desirable.

I completely understand that you'd rather sort by the time stamp than by filenames, but the default behavior now on ext3 filesystems is to sort by directory hash order. I can imagine lots of desirable sorting criteria -- ctime, filename, mtime, etc. -- but I can't imagine any situation in which "sort by the internal storage order of directory entries on the hard drive" would be useful to anyone. :-) The other issue is predictability. Do you really want your module, which functions at an application level, to behave differently depending on the underlying filesystem format on the hard drive?

All that being said, I think your idea of making the sort order more configurable is a good one and will see if I can free up some time to work on it.

As an interim solution, would you accept the patch as-is if I add a simple boolean configuration option to enable or disable it, so that users who don't want this sorting step don't have to use it? I could implement this a lot faster than a generalized sorting interface.

With regard to your idea of a more general interface, I would suggest that the sort order be in the mass import page, so the user can choose it for each upload depending on the nature of the images -- but have a similar dialog on the module settings page to allow the system admin to set the default sorting order for the site. Comments?

Kind regards,

Syscrusher

vhmauery’s picture

Yes, I forget that ctime in php is a unix timestamp despite the underlying system call (in Linux) having nanosecond precision. But even on a fast system, tar saves the original timestamp, thus ensuring the original ctime. This means that sorting by ctime is not all that inappropriate. But I am okay if you would like to sort by something else.

I think the mass import page is a good place to put the sort option.

I would rather see a final patch than commit an interim fix.

ricmadeira’s picture

Glad you found the problem, Scott! Not being able to get images properly sorted out in mass import has been a major source of frustration with acidfree since the very beginning.

Hope you can make this an optional setting (for me, filename sorting is just fine since my camera labels the photos sequentially) so Vernon will commit it to CVS. I'll try to patch my 4.7 with this in the meantime.

vhmauery’s picture

Version: 4.7.x-1.0 » 5.x-1.x-dev

I am re-targeting this issue to the Acidfree 5 version. Eventually, this is where the code should show up.

mwheinz’s picture

Version: 5.x-1.x-dev » 6.x-1.0-beta2
Assigned: syscrusher » mwheinz
Category: bug » feature

Boy, this would be nice. Changing version to 6.x and assigning to myself.

mwheinz’s picture

Status: Needs work » Closed (duplicate)