Shared files is a hot issue for many people. It seems that
the developers are waiting a bit on further developers before they create the ultimate solution.
I would like to propose a quickfix (that unfortunately I am not able to implement).
Functionality I would like
Currently we have course files (for all courses) and site files (for course id = 1). I would love to be able to access the site files from the course files interface.
That way it is possible to create your own file repository of resources that are available from any course.
In a *nix environment this is quit easily realised by creating a symbolic link from the course files directory to the site files directory. The problem is that the symbolic links turn non-symbolic in the backup-restore process and inflate the site terribly.
What areas need to be changed?
files/index.php: The logic here should be changed to not only show the files of the course but also the files of course_id = 1
Backup/restore process: Backup and restore should be aware of the fact that the site files are accessed from the course and should not duplicate them or back them up.
HTML editor: When I add a link or insert an image in the HTML editor I can access the course files. This needs to be updated to also show the files for course_id=1
Did I miss something?
Am I wrong is assuming that this would not be terribly hard to implement? How much money would I need to spend to get this right now?
The problem is that the symbolic links turn non-symbolic in the backup-restore process and inflate the site terribly.
Yes, this is exactly the problem I have been having also. I have been using linux symbolic links, but the big problem has been the bloated backups. I only realized how bad it had got when my server crashed because the hard disk had filled up!
I am interested in your proposed solution, because this has become a big problem for me. Now I have had to delete the symbolic links from all courses except current ones. The only other alternative to this would seem to be to disable the backups - which is not a good security policy of course!
There have been a few hacks which have not been continued - I remember that Teemu's one was very promising but unfortunately development has stalled. There is also the My Files block from Michael Penny et al and now he is developing a very interesting My Files with WebDAV (it is registered on sourceforge). Would either of these solutions solve this problem? I'm wondering whether it might be good to see whether these are about to be released before taking another tack?
The only possible concern I have about your solution is that unless a login is required for the frontpage (course=1), these files are not password protected and students may tell each other the file names so others can download them too.
If I am wrong about that and also if there is no possibility of one of the projects above coming through soon, then I would be prepared to chip in some money to get this feature developed asap! That is how much I need this problem solved.
Interested to hear from others,
Tim.
Yes, this is exactly the problem I have been having also. I have been using linux symbolic links, but the big problem has been the bloated backups. I only realized how bad it had got when my server crashed because the hard disk had filled up!
I am interested in your proposed solution, because this has become a big problem for me. Now I have had to delete the symbolic links from all courses except current ones. The only other alternative to this would seem to be to disable the backups - which is not a good security policy of course!
There have been a few hacks which have not been continued - I remember that Teemu's one was very promising but unfortunately development has stalled. There is also the My Files block from Michael Penny et al and now he is developing a very interesting My Files with WebDAV (it is registered on sourceforge). Would either of these solutions solve this problem? I'm wondering whether it might be good to see whether these are about to be released before taking another tack?
The only possible concern I have about your solution is that unless a login is required for the frontpage (course=1), these files are not password protected and students may tell each other the file names so others can download them too.
If I am wrong about that and also if there is no possibility of one of the projects above coming through soon, then I would be prepared to chip in some money to get this feature developed asap! That is how much I need this problem solved.
Interested to hear from others,
Tim.
Sorry, I can't help you with the proposed changes. Your explanation of the use of symbolic links and the bloated backups they cause, made me think of a quick and dirty solution.
The function course_files_check_backup in backup\backuplib.php
automatically skips the backupdata directory. (Otherwise you would end up with course backups with an earlier backup enclosed)
If I am not mistaken it's easy to add other directories to exclude as well.
If you make sure that all the directories which are in fact only symbolic links to another course directory start with _duplicate_ you could exclude them from backup.
Look for the lines:
//Check it isn't backupdata_dir
if (strpos($dir,$backupdata_dir)!==0) {
//Insert them into backup_files
and change the second line to:
if (strpos($dir,$backupdata_dir)!==0 && strpos($dir,'_duplicate_') !==0 {
I haven't tested this because...
I couldn't work out how to use this symbolic linking in my testinstallation
It's not a nice solution, but if you're happy continuing the symbolic linking trick, this might prevent the bloated backups.
Thanks a lot Jan, I will test this ASAP. It looks like a very good prospect! 
Tim.
Tim.
Hello Jan,
I will also try this out as soon as I can. I know it is a slightly dirty solution, but I do think it can save me a lot of work.
Do you know what would happen if I make this change and then do an update of my Moodle installation through CVS? What if backuplib.php would be changed in the updated version? Will I lose my changes or will it not update (using the standaard "cvs update -dP" command)?
Thanks for a smart intermediate solution!
I will also try this out as soon as I can. I know it is a slightly dirty solution, but I do think it can save me a lot of work.
Do you know what would happen if I make this change and then do an update of my Moodle installation through CVS? What if backuplib.php would be changed in the updated version? Will I lose my changes or will it not update (using the standaard "cvs update -dP" command)?
Thanks for a smart intermediate solution!
Tim, Hans,
After rethinking this, there may be a solution which doesn't require any code changes: Just make sure all of the symbolic links are placed inside
the backupdata directory or
any directory that has a name starting with backupdata
That way, I think, they will be automatically excluded from the course backup.
Jan,
I tried your first hack suggested above, that of editing the backuplib.php file, but for some reason it didn't work.
However the second and simpler one did work - on my test it reduced the backup file from 245 to 64 MB! It seems such a simple solution, thanks a lot for pointing it out.
This is an enormous help to me Jan - I will be able to use the symbolic links to share files without the terrible side-effects. Now I can patiently wait for the DMS to provide a more integrated method to share files between courses.
I appreciate your help, many thanks,
Tim.
PS The symbolic link is set up with the command "ln -s /path/to/sharedfiles/folder" in a particular course files folder
I tried your first hack suggested above, that of editing the backuplib.php file, but for some reason it didn't work.
However the second and simpler one did work - on my test it reduced the backup file from 245 to 64 MB! It seems such a simple solution, thanks a lot for pointing it out.
This is an enormous help to me Jan - I will be able to use the symbolic links to share files without the terrible side-effects. Now I can patiently wait for the DMS to provide a more integrated method to share files between courses.
I appreciate your help, many thanks,
Tim.
PS The symbolic link is set up with the command "ln -s /path/to/sharedfiles/folder" in a particular course files folder
Do you know what would happen if I make this change and then do an update of my Moodle installation through CVS?
What if backuplib.php would be changed in the updated version? Will I
lose my changes or will it not update (using the standaard "cvs update -dP" command)?
Hans, I can answer those questions. CVS will never overwrite any edited lines when you update Moodle.
If the line has not been altered in the new version of Moodle, then the edited line will be left alone as is.
If the line has been altered in the new version of Moodle, then the CVS update will flag a conflict and will add conflict markers surrounding the conflicting line(s). In this case, you would have to edit the file and delete the conflict markers to get your Moodle site operational again. Everything else, however, will still be updated.
I will post about Jan's hack as soon as I test it.
Tim.
Hans, I can answer those questions. CVS will never overwrite any edited lines when you update Moodle.
If the line has not been altered in the new version of Moodle, then the edited line will be left alone as is.
If the line has been altered in the new version of Moodle, then the CVS update will flag a conflict and will add conflict markers surrounding the conflicting line(s). In this case, you would have to edit the file and delete the conflict markers to get your Moodle site operational again. Everything else, however, will still be updated.
I will post about Jan's hack as soon as I test it.
Tim.
The following fix works on our site (the one before just changes the shown number of files):
/backup/backuplib.php: Line 1758:
if ($dir !==$name_moddata and $dir !== $name_backupdata and !is_link($rootdir."/".$dir))