How are you changing the order?
in general, you won't get any specific order when reading from a directory (at least not one you may rely on), you'll have to sort them.
for example, if your user sets a priority on each image, you might just say (assuming you build a hash named %imgprios with ('filename' => prio), where prio is an integer or float)

for my $elem (sort { $imgprios{$a} <=> $imgprios{$b} } readdir(DIR)) {
# cool code goes here
}

Hi Janharders,

I have a directory with photo files as 001.jpg, 002.gif, 003.jpeg, ..... so on. I also have a text file in the same directory tracking the photos, its content has the photo file names. The content of the text file is like:

001.jpg
002.gif
003.jpeg
004.gif


The first part of my Perl script uses the text file to call up each photo file in the order of the text file content and list them one by one in the numeric order.
The middle part of the script has a user interface to re-arrange the order. For example, the user click a button and the script will use the feature from File::Copy and File::Copy::Recursive to do "move", "copy", "rmdir" ...to arrange the filenames.
And then read and output the text file to rearrange the list.

The photo did change in the diretory successfully. The text file did change correctly too. However, the script loops back to the first part to display the photos again, the displayed photos still show the old order.

I can see the correct new order by closing the Window, start a new Window and call up the script again.

If I do not close the Window and just click around in the same script. The order does not change. The display order still shows the old order.

That is why I am thinking there is a RAM/BUFFER storing the old data, I need a way to flush out the old data and force the script to read the new data from the text file and directory photo files.

you haven't really described the problem completely enough to gave a conclusive answer.
perhaps you have an object or data structure which needs to be reinitialized.

[i hadn't seen your 2nd response when i posted my response]

are you flushing the buffer when you rewrite the file?

Thanks for a quick reply.

Yes, how to flush out the downloaded data. Somehow I think there is a place Perl keeping the downloaded data and does not replace(flush) with the new data. May be Perl thinks it is not necessary.


May be I am not using something high level to handle the photo display. I just use simple OPEN file to open the text file which has the list of photo file names in the directory. Like

001.jpg
002.gif
003.jpeg
004.gif

Once the OPEN HANDLER get one line from this text file, my script will use the filename(one line) to display the photo. Then one line and one photo at a time, until all photos are displayed on the screen in that order.

Then I use a href for user to click a up1 or down1 button. When a user click the up1 button. My script will pass a parameter(up1) to the same script to run from the top, when my script sees the parameter(up1), it will go into a COPY, MOVE, ...operation to change the photo files in the directory. It also goes into the text file to swap the two lines. After this operation, the script will run through the same OPEN file and read through the text file to display one photo file at a time until all are displayed.

After the operation, the photo files got changed correctly. The text file got changed correctly. But the display still has the original photo order.

If there is a way to force the OPEN HANDLER to read the text file again, the display order will be corrected. Seems like the OPEN HANDLER thinks it is not necessary to update and dump out what it had.

there are several methods to do this.
you should read this:
"How do I flush/unbuffer an output filehandle?" [perldoc.perl.org]

Since it's correct when he re-opens the browser, I'm guessing it's caching.
try disabling browsercaching for the script, add

print "Cache-Control: no-cache\n";
print "Pragma: no-cache\n";

before printing the content-type header.

I was thinking it was caching from the start, but wasn't sure. :-) Alternatively,


$rand_num = &some_rand_num_function;

img src="001.jpg?$rand_num"

Where some_rand_num_function generates a unique number based on user's IP and time. Even if the same random number is applied to all images on a given page, it will trick the browser into downloading a fresh copy when it errantly doesn't recognize it's modified.

The down side is, it will always download a fresh copy and will never cache any images, but neither will setting no-cache headers.

From what I understood, his images do not change, just the page including them, and there, mostly the order. So his images might still be cached, it's just the link back to the original presentation page that needs to have it's url completed with a hint of randomness.

Also, if the images themselves were wrongly cached, it might work to tell the clients that the policy is "must-revalidate", but I'm not sure which clients honor that and which don't, since I usually don't care for bandwidth, because it's so cheap over here ;)

i missed this in jscjso's second post:

I can see the correct new order by closing the Window, start a new Window and call up the script again.

If I do not close the Window and just click around in the same script. The order does not change.

in which case i would agree with janharders and rocknbil about it being a likely cache problem.

Gentlemen,

It was my mistake to use the word "buffer" in the first note to lead you into a wrong thinking of BUFFERing. I did researched the flushing buffer and use hot handler after seeing the response. It has some draw back then I saw rocknbil message. That completely woke me up.

Before I started this thread, I tried these.

1. I tried to trick the "buffer"(should be cache now I know) by changing the text file name and back. The cache did not got updated.

2. So I made a bigger attempt by changing the whole directory name and back. The cache did not got updated.

3. Then I changed the name of the whole directory to "tem" directory and process the display using the directory "tem". And then copy the directory back to original name. Yes it works this way just during the moving photo up and down section. Yes, I had to use COPY not MOVE to create the original directory name. If I used MOVE, I think the display operation works fast and caught up with the MOVE. The display operation could not find the tem directory. That was
the reason I used COPY to make the original directory.
This way, I left with a tem directory behind.

On the next run, there is a tem folder there and messed up the second run of display because it will generate another tem directory. So I created a random generator with 8 digits. So the tem######## will never be repeated and works for many rounds of display. I was planning to create a timed scheduler to rmdir <tem*> once awhile.

I thought that work. Yes it did, but only on that spot. My script has other sections displaying the photos. The same old cache started to show up again.
This time, the display involves a lot more complicate operation. I had no way to create so many temporary directories everywhere.

That was the time I knew there must be a better way. so I started this thread.

Wow, once I saw the idea of attaching $randomNumber to the end of img. I was completely overwhelmed with the idea. I did not know I can add ?#*$! to img. I quickly add ?$randomNumber to the img, it works perfect.


janharders, phranque, rocknbil,

I am very appreciated you quick suggestion and help. I was not clear in the first couple of notes. I just did not know what to refer my problem to. It is very unique. Thanks, I got a perfect answer from you. This method does not slow down the Perl processing.

Thanks again.