[ET Trac] [Einstein Toolkit] #1772: Simfactory: potentially serious problem with CACHE directory in the simulations directory

[Einstein Toolkit]

#1772: Simfactory: potentially serious problem with CACHE directory in the
simulations directory
-------------------------+--------------------------------------------------
  Reporter:  bmundim     |       Owner:                     
      Type:  defect      |      Status:  new                
  Priority:  critical    |   Milestone:  ET_2015_05         
 Component:  SimFactory  |     Version:  development version
Resolution:              |    Keywords:  CACHE              
-------------------------+--------------------------------------------------

Comment (by hinder):

 I've just looked at the relevant function
 (https://bitbucket.org/simfactory/simfactory2/src/9c19923096de7cefe1efc903037aff0440807f3f/lib/restartlib.py?at=master#cl-576).
 It is definitely not deliberately creating symbolic links.  If the system
 is configured to create symbolic links instead of hard links, I agree with
 Erik that that is an incorrectly-configured system.  Unless you can make
 the system administrators see sense, SimFactory is going to have to check
 whether the created file is a symbolic link, and if so, remove it and use
 copying instead.

 Replying to [comment:5 eschnett]:

 > And with "right executable" I mean that it is the same executable, byte
 for byte, as determined by an actual comparison, as the one in the source
 tree.

 The logic is currently a bit weird:

 If there is no cached file with the same leaf name as the destination,
   Copy the source to the destination
   Try to hard link the destination to the cache file
   If it fails, copy the destination to the cache file
 else (there is already a file with the same leaf name as the destination),
   try to hard link the cache file to the destination
   If it fails, copy the cache file to the destination
   [This is potentially a waste of time if you haven't first compared that
 the files are equal; it could just as easily be a new (or old) executable]

 If the source file has a modification time before or equal to that of the
 destination file, and the sizes are equal, call the source and destination
 files "equal" (??? this means that submitting an older executable with the
 same name will use the older executable)

 If the files are not "equal" as defined above,
   Remove the destination file
   Copy the source file to the destination
   Remove the cache file
   Hard link the destination to the cache
   If this fails, copy the destination to the cache

 Am I missing something, or is this logic fairly weird (and wrong, in the
 case of an older executable)?

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1772#comment:7>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit