No, this was all an idea I've had for a while, but never did anything about it. I'm pretty sure the Galaxy developers are not interested in anything this locally-centric, and I don't blame them. It ought to be something outside the Galaxy build completely, because Galaxy is meant to be system-independent.
What I meant by 'joint user/galaxy directory' is a directory that is owned by a user, but that the galaxy user has read (and possibly write) access to. This is entirely possible given either a well-informed user population, or an iron-clad suexec executable. The mechanism I alluded to is a feature by which a user can upload a directory of files all at once. There is a configuration directive in universe_wsgi.ini, user_library_import_dir, that allows non-administrative users to upload an entire directory of files into a library. The directive identifies the base directory, within which subdirectories named as the galaxy user login (email address) are searched. The user_library_import_dir directory is owned by the galaxy user, and the subdirectories are owned by the user, but group owned by the galaxy user. A user will copy files to the subdirectory, login to galaxy, switch to their library, and upload all the files in the directory into a single library folder. There isn't much documentation about it in the main Galaxy wiki, so forget that. I haven't enabled it in our local production site, and I haven't played with it in a long time. I'm pretty sure that the files are not removed after uploading, and a user is free to re-upload the files again and again, so it's kind of quirky. Also, if the files are not readable by the galaxy user, a bizarre and unhelpful error is thrown. If this functionality could be extended and elaborated, it could do what you want. The user_library_import_dir requires that the user's login in Galaxy must be identical to the the user's login on the cluster, and that the permissions be kept correct. Typically users have no idea what is going on with their permissions, so what are you going to do? David On May 16, 2012, at 1:33 PM, Josh Nielsen wrote: > Hi David, > > Actually that is an interesting idea to use a daemon to move the files into > associated user directories. Is that something that Galaxy Dev is working/can > work on, or was that just a suggestion? I'm not opposed to doing any dev work > of my own, but I don't really know Python that well and I know most of the > Galaxy code is Python. > > I'm not sure that I follow what you are talking about with the joint > user/galaxy directory though. I'm of course wanting it to not be unified (not > all in the same directory) and rather be segregated by user into user > subdirectories, but I think you already caught that so I guess I just didn't > understand what you were getting at. > > Josh Nielsen > > ---------- > >How about if there were a completely separate daemon that monitored the > >galaxy database periodically to determine what datasets belong to which > >user(s). Then > >it would move the actual dataset to an area owned by the user and group > >accessible to galaxy, replacing the dataset with a symlink. This would > >require no changes to the galaxy build, but it would require a constant > >monitoring system. > > >There is already a mechanism for users to move their files into a joint > >user/galaxy directory, but it is (as far as I know) only allowed for > >libraries, not > >histories. It would be better if there were a way for users to browse > >through their own directories as a tool, and be able to load files directly > >into their history. > > > >David Hoover > > ___________________________________________________________ > Please keep all replies on the list by using "reply all" > in your mail client. To manage your subscriptions to this > and other Galaxy lists, please use the interface at: > > http://lists.bx.psu.edu/ ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/