When I import a .zip file with images, the nodes for the images are created in what seems a random order. Just look at this example (the message is displayed by the pathauto module; I'm using it because it shows the images are created out of order):
Importing MotA.zip
Created new alias fotos/2005/11/img_2479 for node/680
Created new alias fotos/2005/11/img_2484 for node/681
Created new alias fotos/2005/11/img_2485 for node/682
Created new alias fotos/2005/11/img_2480 for node/683
Created new alias fotos/2005/11/img_2478 for node/684
Created new alias fotos/2005/11/img_2481 for node/685
Created new alias fotos/2005/11/img_2483 for node/686
Created new alias fotos/2005/11/img_2482 for node/687I took care to create the .zip file in order, from img_2478 to img_2485, so there doesn't seem to be a direct explanation for this.
Something like this used to happen too when we used the mass import function to upload various images at the same time. That bug got fixed long ago, so maybe this could be sorted out too? ;)
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | acidfree.diff | 3.81 KB | EvilBill |
| #6 | acidfree-importdir-order.diff | 961 bytes | EvilBill |
Comments
Comment #1
vhmauery commentedcan you please email me a zip file that is not working for you. I cannot recreate this. I uploaded a file with 10 images/videos in it and all the files got imported in the correct order. Make sure to email it to me because posting it here will fail because it is too big.
Comment #2
lakyljuk commentedI would be happier if problem with blank page displayed could be corrected sooner then this bug, but I have to add to this, that I have the same problem with importing zipped images - they are imported in random order. On disk they are named like Image01, Image 02 etc. After packing them and uploading this archive, they are imported into album in random order. I was trying to find any pattern they were imported according to. But order is simply random, they are not even ordered by date or else.
But as I said - this bug annoys me less then "blank page bug". Although I acknowledge that this can be worse for somebody.
lakyljuk
Comment #3
vhmauery commentedWell, whatever the priorities are on either bug, I cannot reproduce them myself. So neither one is very close to getting fixed.
Comment #4
lakyljuk commentedWell, others realised this too so there is some hope someone can find a solution. Some "bugs" can be user system related, so you Vernon have no chance to realize what's going on. It can be something wrong with modules installed and not working properly together or any other difference from configuration that you have. Anyway - thanks for any effort and time spent on this.
lakyljuk
Comment #5
vhmauery commentedThe line that has the unzip command has a -qq on it. If you delete that option and import, it should print out the files in the order it extracted them from the archive. Can you make sure that they are getting extracted in the right order?
Comment #6
EvilBill commentedMay be related, the import of a server directory does not get ordered either. Here is a patch to fix that.
Comment #7
EvilBill commentedSorry about the title change of the bug report. I thought it would only be the title on my comment. Oops. (Still new to this).
I jumped the gun. Acidfree reverses the order so array_multisort needs to use the "SORT_DESC" flag rather than the "SORT_ASC" flag.
Comment #8
vhmauery commentedI don't want the files sorted alphabetically. I would like them to be sorted by directory entry order. And that is supposed to be what is happening with the current code. I suppose sorting them by modification date might be okay since that is often the directory order.
What I don't get is why the current code results in different order on the various machines... I think what we really need to to get a test case. If somebody could give me a file that does not work on their machine (email it to me), I will test it on my machine. If that file works fine for me, something is messed up here.
Another option is for someone else to tell me if repeated uploads of the same zip file are resulting in the same seemingly random order of picture imports. This should also help to determine the location of the problem. If it really is different every time, things are getting out of control.
Here are the questions I need to have answered to get this bug fixed.
EVERYONE who has posted to this bug should respond with answers to these questions. I only have a limited number of platforms to test on -- Debian Sarge and Ubuntu Breezy, both with ext3 filesystems.
Comment #9
EvilBill commentedOn Import Directory:
I am copying images from a FC4 server with scp *.* user@remote:/tmp/Images. Since the shell expands the *.* on the command line, the images are copied in "order", e.g. in my case it is "dscf0001.jpg" then "dscf0002.jpg", etc.
Linux home.system 2.6.13-1.1532_FC4 #1 Thu Oct 20 01:30:08 EDT 2005 i686 i686 i386 GNU/Linux
These files are copied to a RHEL3 system (as I mentioned to /tmp/Images) for mass import.
Linux server.name 2.4.21-37.ELsmp #1 SMP Wed Sep 7 13:28:55 EDT 2005 i686 i686 i386 GNU/Linux
php-4.3.2-26.ent
After import (without the patch), the files are mostly random (maybe?) with the first loaded up appearing last in the image gallery. If I do a "ls -lf" on the remote server, the files are displayed in the order copied. I verified this by copying "00First.jpg" into the directory and with "ls -lf" it appears last in the list.
If I comment out the "array_multisort" line in my patch, the files DO show up in the reverse order that I uploaded them. I.e. the 00First.jpg is the first image (although the last uploaded) and the dscf0001.jpg is the last image (first uploaded). That is, the image order is the reverse of how I uploaded them.
If I revert the code to not have the read-dir, it seems that it does the same thing as explained in the last paragraph. That is, the last image uploaded is the first image in the album.
I see now that they are imported in directory order but the node display order is descending. So my 00First.jpg image gets e.g node 1606 and my first uploaded image gets node 1584 but node 1606 is displayed as, I guess, the "most recent image" and hence first in line in the gallery. Not really what I want when I bring my camera home from a party. I want the first pics of the evening shown first in the gallery. Perhaps an option for the gallery on the display order?
So I guess there was some confusion on my part. (I am good at that.) I am not sure that the order was really random because I was importing 100-200 pics at a time and just knew they were not in chronological order.
It might be nice to have the sort an option for import. I can make a patch for that if you want.
Comment #10
EvilBill commentedHere is a patch to allow the user to select the import order for a mass import.
Comment #11
xe commented1. ext3
2. redhat linux
3. same random order every time
4. random, same pattern every time
btw, the patterns in 3 and 4 differ.
Comment #12
sahughes commentedUsing the latest acidfree code for Drupal 4.7.0 (RC3) I am also experiencing the problem reported and discussed above. This problem is not limited to importing .zip files, however, as it also occurs when mass importing local files.
I have spent considerable time looking into this problem, with some dumfounding inconsistencies and since the issue is a little broader than suggested above I will submit a new bug report and detail my findings there.
Comment #13
sahughes commentedIf you contact me directly, I will supply you with a test machine with Drupal and bash access so that you can reproduce the problem.
Comment #14
vhmauery commented