We have an issue with Liferay: when we delete a folder from the Document Library, with some documents inside, the corresponding disk files are not deleted. They are still in place even when the folder is removed from the Liferay Trash Can, and their size is still the full file's size.
When we delete documents directly, this issue does not happen: files are removed from the disk as soon as the document is moved to the trash inside Liferay.
This is a great issue for us since we are not able to free up disk space (a procedure to find already deleted documents and remove their files from the disk would be useful).
The only similar issue I found is this one:
https://www.liferay.com/it/community/forums/-/message_boards/message/3399338 ; I already checked that the user running tomcat has the correct filesystem permission.
This issue occurs on two different environments (staging and production) with the same configuration.
Our configuration uses AdvancedFileSystemStore for the Document Library and our Liferay version is Liferay Portal Community Edition 6.2 CE GA2 (Newton / Build 6201 / March 20, 2014).
EDIT: I still haven't found a solution to this problem, but I was able to find and remove deleted files from the filesystem thanks to this app:
https://www.liferay.com/it/marketplace/-/mp/application/49321947
It lists all files existing on the filesystem without an entry in the database, and let you delete them.
Related
Someone uploaded (attached) a file in a Gitlab issue comment. They did not mean to share that file publicly. I can delete the comment, but the file is still available via the original direct url. The file is at:
https://gitlab.com/<username>/<repo>/uploads/<hash>/<filename>
Is there any way to completely remove files from this uploads directory?
Short version: There's server-side Uploads administration | GitLab, but little to nothing else.
TLDR:
For the owner of a repository, there seems to be no way to get hold of these uploads directly, there even doesn't seem to be a way to list all uploads pertaning to a specific repository (or user/owner), let alone modify them.
use-cases where this would be desirable:
deletion of data that should not be exposed but has been erroneously.
down-scaling of oversized files (images, pdfs, etc)
replacing files with updated versions
deleting space-hogs that are no longer needed.
deleting files that got uploaded accidentally by trigger-happy mice or when the result of a previous upload didn't show in time for the impatient user.
Making these files changeable would cause several issues rooted in their current/previous immutable status:
Users aware of this status will frequently re-use the url to an already uploaded file for perusal in other issues, or the associated wiki (even across projects) to avoid duplication. Afaik, there is no such thing as a link-count for upload items, so deleting an item might result in orphaned references, and changing an uploaded file might render other references out-of-context.
It would solve the serious issue of leaked information, though. The only way I have found so far to remove a file would be to send a prayer to the administrator of the gitlab server, and ask him/her to take care of the uploads directory on the server, as described in Uploads administration | GitLab
I work in ExpressionEngine v2.11.9 and I am trying to replace a file with an updated version and want to keep the same name so I don't have to update all the instances the file is linked on our website. However, when I delete the file and upload the new version, it replaces it with the deleted older version. We have also been experiencing files that were deleted from the Asset Manager still coming up in a search for that document in an online browser. For clarification, we have not had this problem until recently. Previously, I have been able to upload the new version of this document and "replace" the current version and it updates. Yet, it has stopped doing that. Also, when I delete a file in the Asset Manager, typically the filepath is broken when trying to access it from the website. However, in this instance, after deleting the file, it still pulls up the deleted file from the website.
Please let me know if you have any questions or require more information.
Thank you,
Beth
We are moving form Pentaho 3.8 to Pentaho 7.1, quite a some upgrade. :)
However many things has changed, so I need some help every now and then. On 3.8 we have had folder on HDD where we have had all our reports stored. I am quite used to manage this folder through SVN, so I was trying to do it same way on Pentaho 7.1 but its not working.
At first I have switched pentaho-server/pentaho-solutions/system/jackrabbit/repository.xml back from postgres to FileSystem settings.
However it did not worked. I could not find folders created through web app on HDD.
Next step, I have tried to crerate folder on HDD, located in pentaho-server/pentaho-solutions/. added also index.xmlvfile to recognize it and refreshed/restarted all I could find in pentaho, inculuding pentaho itself. Still can't see this folder in web app.
Now I am searching for possible location where to maintain those files, but there are so many possibilities, I could spend days working on it.
Can someone give me a hint or was doing something similar?
My system is Linux, and I use Community Edition of pentaho-server.
Pentaho only uses Jackrabbit for storing the repository since version 5. There is no longer a physical copy in your hard drive.
Your best shot is using CBF2 and the import/export scripts to sync the jackrabbit repository and a folder on your drive you can then sync using SVN.
CBF 2 blog post
I'm working with a legacy application that's using Liferay 4. They have a bunch of files on display using the Documents and Media portlet. I can see all of these files listed but when I go to view them or download them I get errors. I even tried going into the Admin Console and got the same issue. I can see all the files listed but when I go to download them I get errors.
There are some recent files from last month that were uploaded and those files are able to be viewed. So I get the feeling something happened a few months ago that deleted these files. From what I've gathered the files are stored on the server and the file information is stored on the database. If that's true it would explain why the files are being listed but not view-able/downloadable; if they were deleted from the server but their meta-data remains in the database allowing them to be listed.
According to this page, https://www.liferay.com/community/forums/-/message_boards/message/6387093, the files should be under data/document-library but I believe that's only for Liferay 6.
So where are these files being stored for Liferay 4?
Default settings for a portal come from a file Portal.properties. For Liferay 4, I found this documentation:
http://content.liferay.com/4.2/doc/installation/liferay_4_customization_guide/multipage/ch01s02.html
It states:
#
# Set the directories where documents are stored. This is now deprecated
# because documents are stored in Jackrabbit.
#
dl.root.dir=/home/liferay/documentlibrary/root/
dl.version.root.dir=/home/liferay/documentlibrary/vroot/
and
##
## JCR
##
jcr.initialize.on.startup=false
jcr.workspace.name=liferay
jcr.node.documentlibrary=documentlibrary
jcr.jackrabbit.repository.root=/home/liferay/jackrabbit
jcr.jackrabbit.config.file.path=${jcr.jackrabbit.repository.root}/repository.xml
jcr.jackrabbit.repository.home=${jcr.jackrabbit.repository.root}/home
jcr.jackrabbit.credentials.username=none
jcr.jackrabbit.credentials.password=none
In newer versions of Liferay, the defaults can be overridden in the file portal-ext.properties or in the database.
You might look for hints at these places.
I'm trying to remove sample data (Welcome screen and everything else) from my Liferay server.
I tried to:
remove all directories from the webapps directory except ROOT directory
create new (blank) portal-ext.properties in ROOT/WEB-inf/classes (there was no portal-ext.properties file)
search via Google :)
Nothing of the above helped. Thank you for your advices.
You might have configured a database, or are using the built-in demo hsql database. This holds all the regular data. If you've configured Liferay to access another database either remove the tables from that database or point to another one. There's also the document library that holds documents and images (the binary content). By default they all live in the data directory, on the same level as your tomcat directory (assuming you use a bundle)
A new blank portal-ext.properties will not help you, as it overrides all the standard values defined in Liferay. If there's no content, you're using all the default. And the file should rather be in ${liferay-home}, e.g. the directory that also has the tomcat directory in a bundle.
As you've removed all content and bundled webapplications anyway, you can also just install a new bundle in another directory and use it, pointing it to a new database.