in a scheduler action i need to add files to FAL (to sys_file) which are already in the storage, uploaded via ftp. The normal way
storage->addFile(....)
which copies the file from a temporary folder to the file storage and adds it to the sys_file table does not work, because the file is already in the fileadmin directory. If i try i get this error message:
[ERROR] Cannot add a file that is already part of this storage.
How is it possible to add a file to sys_file which is already in fileadmin?
Thanks!
AFAIK addFile() is to be used for files uploaded from a local disk. If the files are already available on the remote server, you should go for addUploadedFile() instead.
Related
This guide indicates that you need both a file directory and sql file to accomplish this, does anyone know a workaround?
https://localwp.com/help-docs/how-to-import-a-wordpress-site-into-local/
You can retrieve the backup archives from the starting-site folder. Within your WordPress folder, navigate to wp-content -> uploads -> backwpup-xxxxxx-backups. Open the archive. Inside you’ll find a .SQL file (local.sql).
Moodle stores references to all files uploaded to it in its database, the files themselves get hashed and stored on disk but you cannot work out what the files are by looking at them on the disk.
Is there somewhere in the Moodle interface that lets you browse all the files that have been uploaded as an admin?
Is this available as a plugin? Looking for some kind of global file store browser.
Now that google chrome handles zip files, basically, is there a way from inside a chrome app to get the files, and the contents of the files in a zip archive? From the user end, a zip file is mounted as a drive, containing the contents, but from the app end, the zip file is just a file. Is there a way from the app to "mount" the file, get the mount point and enumerate the contents and inflate them?
Nope, there are no particular APIs exposed that would allow this.
You will need to include your own ZIP engine - be it in JavaScript or in (P)NaCl. Then you can work with HTML Filesystem to hold inflated files while you work with them.
I have a file upload page that takes a file and parses it.
Order of Events
user uploads file
uploaded file gets copied
copied file gets it's encoding checked, with CPDetector
determined encoding from the copied file is used to parse the original uploaded file
FileNotFoundException on Solaris Test Server during BufferedReader creation.
copied file is deleted
uploaded file is parsed/verified
parsed data is saved to a database
uploaded file is deleted (I can't remember if I'm doing this or Tomcat is.)
The Whole process works on my Windows 7 workstation. As noted above it does not work on my Solaris Test Server. Something(I Suspect Tomcat) is deleting the uploaded file before I can finish parsing it.
I've watched the directory during the process and an uploaded file does indeed get created, but it lasts less than a second before being deleted. Also It's supposed to go into /opt/tomcat/ but seems be getting created in the /var/opt/csw/tomcat6/temp/ directory instead.
Thanks for any help
I realize it's probably bad form to answer my own question like this but I wanted to leave this here in-case it helps someone else.
The Problem turned out to be How I was accessing the files.
I had hard-coded file paths, for windows, and Database loaded ones for the test server.
I switched those to using System.getProperty("catalina.home")+"/temp/" + filename
I'm also copying the temp file a second time so I end up with:
Order of Events (changes are in bold)
user uploads file
uploaded file gets copied
copied file gets it's encoding checked, with CPDetector
uploaded file gets copied again to ensure a copy survives to be parsed
determined encoding from the copied file is used to parse the original uploaded file
copy used for encoding detection is deleted
copy for parse is parsed/verified
parsed data is saved to a database
parsed file is deleted.
uploaded file is deleted (I'm not sure if I'm doing this or Tomcat is.)
I am using CGI.pm version 3.10 for file upload using Perl. I have a Perl script which uploads the file and one of my application keeps track of different revisions of the uploaded document with check-in check-out facility.
Re-creational steps:
I have done a checkout(download a file) using my application (which is web based uses apache).
Logout from current user session.
Login again with same credentials and then check-in (upload) a new file.
Output:
Upload successful
Perl upload script shows the correct uploaded data
New revision of the file created
Output is correct and expected except the one case which is the issue
Issue:
The content of the newly uploaded file are same as the content of the last uploaded revision in DB.
I am using a temp folder for copying the new content and if I print the new content in upload script then it comes correct. I have no limit on CGI upload size. It seems somewhere in CGI environment it fails might be the version i am using. I am not using taint mode.
Can anybody helps me to understand what might be the possible reason?
Sounds like you're getting the old file name stuck in the file upload field. Not sure if that can happen for filefield but this is a feature for other field types.
Try adding the -nosticky pragma, eg, use CGI qw(-nosticky :all);. Another pragma to try is -private_tempfiles, which should prevent the user from "eavesdropping" even on their own uploads.
Of course, it could be that you need to localize (my) some variable or add -force to the filefield.
I found the issue. The reason was destination path of the copied file was not correct, this was because my application one of event maps the path of copied file to different directory and this path is storing in user session. This happens only when I run the event just before staring upload script. This was the reason that it was hard to catch. As upload script is designed to pick the new copied file from same path so it always end up uploading the same file in DB with another revision. The new copied file lying in new path.
Solved by mapping correct path before upload.
Thanks