<div dir="ltr">Hi all,<div><br></div><div>Firstly, really excited about being able to deploy OMERO5 in production! Nice one.</div><div><br></div><div>As I understand it, once we have OMERO5, we should be able to start working towards having in-place imports of data. This is pretty important for a number of reasons, not least of which is that all our users currently keep copies of everything on a network drive as well as OMERO which is total duplication. Also, it will drastically reduce import times and network traffic. I&#39;m interested in understanding how this is going to work.</div>

<div><br></div><div>I assume that this will require a special import procedure in which the OMERO server is given a path to a file on the local machine instead of data for upload.</div><div><br>Obviously there is no upload step per se although there might be some symlinking or something, then the server would move on directly to doing the metadata import.<br>

</div><div><br></div><div>I have some questions.</div><div><br></div><div><b>Linkage</b></div><div>How would the linkage within OMERO work? An obvious solution is to symlink the file from the managed repository. I don&#39;t think that will work very well because the user will inevitably want to get the path to their data back out of OMERO in the future. If they are given an address in the managed repository then this will mean little to them compared to the original path of their image. </div>

<div><br></div><div>The idea would be that they get this path and can then navigate some proprietary image analysis tool to that location on their network drive and open it. Probably there would have to be config on the server to map the local paths that OMERO users into a sensible path for the user. E.g.<i> /mnt/fileserver1/dpwrussell/data/omero/foo/bar/myimage.dv</i> might be what the OMERO server sees as the image path, but the user would want <i>data/omero/foo/bar/myimage.dv.</i></div>

<div><br></div><div>We would not want to make all the managed repository available to all users because this would violate the privacy of all. I guess an alternative would be to map sections of the managed repository to network user accounts, but this would lose the niceness of being given a path they recognise from their actual data hierarchy.</div>

<div><br></div><div><b>Permissions</b></div><div>Would OMERO deal with making the permissions (or maybe ownership) changes to the files to reduce the risk of deletion/overwriting or should this be done by whatever person/process is marking data for in-place import? I think probably it would make more sense that the person/process do it because they may have to make permissions/ownership changes to make whatever user OMERO is running as be able to see the data at all.</div>

<div><br></div><div><b>Deletion/Overwrite (Worst Case Scenario)</b></div><div>What would happen if a user was to delete/overwrite some data somehow?</div><div><br></div><div><b>Multiple Data Stores</b></div><div>Given that we already have a repository of data, will we be able to add multiple OMERO data directories? One would be all the data that&#39;s already been uploaded and subsequent upload imports. The other would be (in the solution I am envisaging) a mounted filesystem on another server which has a directory per user (it&#39;s basically our current fileserver), this is where in-place imports would be done from so the data doesn&#39;t have to move at all.</div>

<div><br></div><div><b>Moving Files</b></div><div>How about a mechanism for moving a file? I can imagine users having this requirement. Obviously they&#39;d have to go through some special process to allow it to happen. What about moving a file from already uploaded data to the users repository, I know for sure they are going to want this if the above scenario would become a reality. </div>

<div><br></div><div><b>Deduplication</b></div><div>Finally, on a side-note, are there any plans to have a deduplication process? Any file that was previously uploaded with the archive option could presumably now have the pixels removed and perhaps be moved to the managed repository at the same time?</div>

<div><br></div><div>Thanks all,</div><div><br></div><div>Douglas</div><div><br></div><div><br></div><div><br></div><div><br></div></div>