Issue reading from /tmp directory in build environment about mms2r

[monde]

Could you be re-using the same mail fixtures over and over in your test suite? If so, the test suite could be clobbering results. If that is the case you could submit a patch that creates a truely random director for @media_dir

[kbaum]

This could indeed be the case.

For generating random file names, I've had success using:

UUIDTools::UUID.random_create.to_s

Do you think that would make sense?

thx

[monde]

I think you can keep it simple by introducing the current time or a random number as part of the directory hierarchy. Then messages that are processed multiple times will be retained in unique directory hierarchies

@media_dir = File.join(self.tmp_dir(),
                     Time.now.to_i.to_s,
                     self.safe_message_id(@mail.message_id))

or

@media_dir = File.join(self.tmp_dir(),
                     (rand(1e7)).to_s,
                     self.safe_message_id(@mail.message_id))

[kbaum]

I don't like using time since that could break in a multithreaded environment. I'm not sure of the specifics of the rand function but i know uuid is guaranteed to be unique.

  @media_dir = File.join(self.tmp_dir(),
                 "#{self.safe_message_id(@mail.message_id)}_#{UUIDTools::UUID.random_create}")

[monde]

I'm hesitant to bring in a dependency on the uuidtools gem (http://uuidtools.rubyforge.org/) into the main functionality of MMS2R to satisfy an somewhat edge case scenario in a testing environment.

[kbaum]

Makes sense. I would use an alternate method of generating a random unique string if I new it would always work. I have ran into issues in the past with rand methods that were based on time and not always that random.

I'm not too sure that you would never run into a scenario like this in multi-threaded environments. To me it just seems like we are making mms2r that much more bullet proof.

thx.

[monde]

In a threaded environment, given an app like Twitpic that posts MMS media to a feed, if the app starts processing the same message multiple times, then that's a flaw with the application, not with MMS2R. In a scenario like that, the app could work on each message using a work queue, or other similar methodology. MMS2R makes the assumption that each message is unique in terms of the value in its Message-ID header as can be seen in the logic to derive a temporary directory to decode all of its media.

To me, in a threaded testing environment that has no work queue, and is setting up and tearing down the same message fixture over and over, that 1:1,000,000 randomness is good enough. Such as:

@media_dir = File.join(self.tmp_dir(),
                     (rand(1e7)).to_s,
                     self.safe_message_id(@mail.message_id))

[kbaum]

Makes sense.

[monde]

I added your fork into the latest 2.4.0 version if you hadn't noticed, thanks