I have a problem where I need to update a file used by a page resource.
When I try to upload the new file I get the error "file exists already". So if I rename the file and upload it there is no problem, however the old file still remains on the server and this is incredibly annoying if I need to update the file several times for whatever reason.
So the question is: How can you delete a file in the Moodle 2 respository?
Great thanks, after extensive googling I figured somebody here would know. Appreciate that
I assume this only applies to the files copied into Moodle's internal filesystem, as apposed to any 'file repository' set up - eg a File System repo or a connected one such as alfresco (does Moodle obtain any author / deleting rights to external repos?)
Do you know how often those files are detected and deleted?
Let's suppose I've realized that I saved the wrong image in Photoshop, but only after I've uploaded it. So delete it out of the Moodle editor, and try to insert the new image that has the same file name (Because we use a Figure_XX naming convention). Since I deleted the old one only seconds ago, it gives me the "File name already being used" error. While I COULD just rename the file (even as I upload it, I see), is that really the best way?
Hmmm, good question Matt.
I tried this myself. Uploaded a file and linked to it. Then decided to delete the link, which means the file gets deleted automatically. However, it's not instant. I ran the Cron job manually and Refreshed the File picker, but the old file still shows. (I agree there is no logic in being forced to rename a file simply to upload it).
So, it would be good to know how long after a file becomes unused/redundant it can be replaced without the 'duplicate name' being an issue. Maybe this is linked in some way to the Cron tasks that run every 30 minutes - like the Forum editing time?
Anyone know the answer?
Here is a related issue. I am using the "Folder" resource to hold some files that I want students to see and have access to (PDFs, etc). I have noticed that I can add, then delete, then re-add the same file without getting the annoying "File name already in use" (or whatever the error is) error. It seems to know when I delete the file I don't want, and deletes it in draftfile as well.
I think this problem of it not being deleted must be related to the problems we're having inserting images and not having them be seen by anyone but the uploader that I've posted about elsewhere.
I had the same problem in Moodle2.01.
1. Add a resources> Label
2. Click on 'Insert/Edit image' icon
3. Click on 'Find or upload an image' button, get 'File picker'
4. I can see all old images which I uploaded before, BUT don't need any more.
HOW to delete an old file?
Anyone know where are files in server? At Moodle1.9, I can go to moodledata folder to find any files via FTP. But I cannot see my files in Moodle2.0.
Please help me on finding out How Moodle2 store files.
William, unlike Moodle 1.9.x and earlier versions, Moodle 2.+ stores files inside the database. It offers much greater security, and stability, but a little less flexibility, I think. You have to trade these things off each other, there is always a price to pay when you change things, and improved security always means a more rigid structure. That is why you can no longer see your files using FTP. I have no doubt that a new file viewer will eventually be developed that can work inside Moodle's database, but it will be a while.
Wrong, wrong wrong!!! Sorry guys, rushing and not getting it right. If you open the Moodle 2.0.x database you will find a number of tables that were not there in Moodle 1.x.x versions. If you look at these tables then you will notice they correspond to the courses you create and the files you upload. It is easy to see where that previous response is getting it wrong. What they are is not the files themselves, but links to the files and, it seems, secure renamed/storage codes for where Moodle actually puts the renamed files in the moodledata folder. This is a little confusing and it explains one very important reason why it has been so difficult to generate a 1.9.x backup to 2.0 restore process. However, I think I was right about a file viewer to view stored files because I would suggest that it is going to be really hard to distinguish a pdf from a graphic and a spreadsheet by directly access the moodledata folder without the database stored strings to identify files. How you can handle the files from outside Moodle is going to be a difficult task ... but someone will work it out I suspect..
In MOODLE 2.0, the uploaded files are located in the following (Windows) directory ( :
and under MAC OS X , they are in : Applications\XAMPP\xamppfiles\data\moodle20\filedir
The files are renamed by MOODLE and this (crypted) name is stored in the database.
If you go in the filedir directory and rename the file with its original name, you will open your file with your favorite editor (the file has kept its original format.
I've been looking everywhere for the answer to this question but I can't seem to find the answer anywhere.
My question is: How long is it before an unused file is detected and automatically deleted? An hour? A day? A week?
Have you had any luck with this? I have the same question.
I uploaded a file -- sent the link out to a large group of people -- then noticed a typo in the file. I can't get the first file out of the way to upload a replacement of the same name!
I've manually run cron about 100 times in hopes that it will clean it up, as Helen suggests it will.
Good question! (we will try to run some tests locally, but may be HQ tell? )
Overall, I believe that this behavior needs to be fixed, and the "old" file added via the text editor has to be deleted right away.
It is weird when one can delete a file, cannot see it, but at the same time he cannot upload an updated version of the same.
This would slow down course development process, and cause some grouch
We have this behavior with regular Add a resource > File, where system recognises that "old" file has been deleted and allows to reload with the same name.
p.s., I do not get the note on the wiki FAQ:
Q: "How can I delete an embedded file previously added using the file picker?" A: There is no need to do anything, as any unused files are detected and then deleted automatically after a period of time. Users cannot delete files manually, since they may be used elsewhere."
How they can be used somewhere else, if we are not external linking to a file from some other repository?
Because of the new 2.0 behavior we are suposed to be uploading right into the "page"/"label", hence there should not be any other association of this particular file with anything else in the course.
I find this behavious of the file system illogical and a pain in you-know-where. I do NOT want the file system to delete files automatically period and I do want the file system to delete a file immediately once I click on delete (with just a warning if it is linked/used anywhere). Imagine having to wait FOUR days before one can replace a deleted file with another by the same name, ridiculous!
So, we have found out that the logic is hard-coded to delete draft files after four days.
The file that blocks the new file upload (with the same name) sits in the "draft" area.
Thus, if you load file A into the description of the resource (e.g. File or Folder) and attach file B to the same resource, and then delete and try to re-apload update versions with the same names => you will be able to re-upload B. But no luck with A.
Is there any technical reason why we need to wait 4 days to update A?
P.s. I just encountered exactly the same issue, trying to update my screenshot )
If I would be a faculty, I probably would not be happy.
Quick scenario: you are developing a quiz (or series of web pages) and you have your images titled in some unique pattern.
Update: Apparently, the problem is actually worse.
Unless you just happen to have the resource open in the editing mode at the time the cron runs, even the cron (after four days) will not delete the associated file.
I guess Repositories_FAQ needs to be updated to indicate that "attached' file, will get deleted, but "embedded" with the text editor - will not.
Please vote: MDL-26388
Elena -- Thanks for the research and information! You certainly did your homework.
I've voted for the bug; here's to hoping there's a fix soon!