I'm attempting to retrieve a database backup we've put into Cloud Storage. To make a long story short, the url is gs://servername/year/date/data.sql
It's a little more complicated than that, but for the sake of this question, it'll do.
Anyway, when I use the Storage Browser (Projects -> Storage -> Storage Browser), I can get into /server/2014/2014-09/04/ - but this is where things get weird.
The subfolders/directories phase in and out of existence, only for this date. I can go in and out of the bucket subfolder of 2014-09-04 all day, and it'll have different results every time. Sometimes the incremental data is there, sometimes only the schema data is there. Trying to download any file from the storage browser gives a big fat "Not Found" blank error page. No links, no http response codes. Just, "Not Found". All our older dated folders are fine.
If I use gsutil to attempt to retrieve the entire subfolder, it says:
CommandException: No URLs matched: gs://servername/2014/2014-09-04
The command I ran was:
gsutil.py mv gs://server/2014/2014-09-04 c:\dbrestore\
Yet there it is in the storage browser, clear as day. (There is only one ACL, so I know that's not the problem) To make sure I wasn't doing something funky, I have copied dates surrounding it ok, so 2014-09-03 and 2014-09-05 are both completely accessible from the storage browser, and gsutil.
I am out of ideas as to what could be wrong. Frankly, something about the bucket looks stuffed. Has anyone run into this problem before, and if so, what did you do to go about correcting it?
Related
With the Google Speech API (using the python sample code), you need to have your audio files on google cloud when longer than 1 minute. According to some sample code, you can use a path like
gs://python-docs-samples-tests/speech/audio.flac.
So I put my audio files in a bucket, and use (I believe) the correct path (i.e. gs://bucket-name/foldername/myaudiofile.wav), yet I get an error .
NotFound: 404 No such object: bucket-name/foldername/myaudiofile.wav
Even if I put the permission on public (which I rather not do), it cannot find the file. I have the feeling I am forgetting something very trivial here... But still haven't found it.
Go to the cloud console > select the project > go to Storage > Browse the buckets and make sure the file is actually there. Best way you can tell, IMO.
I've done some digging around and a lot of the threads regarding file system and how it works with Meteor seem to be pretty outdated, not to mention packages related to file storage/serving (i.e. CollectionFS). I was wondering if anyone here has deep experience with handling files in lieu of 1.4 or even 1.3 (I am currently on 1.4.1.1).
My questions are as follows:
Did Meteor 1.3/1.4 come with any changes regarding fs?
What is the general best approach to storing and serving static assets in light of Meteor 1.4?
I've seen many threads that say dynamically storing files to /public triggers a server upload, but I've tested this on local by manually copy/pasting a .png file into /public, and it only triggers a client refresh with the console message Client modified -- refreshing. Would this hold true for files added during runtime, and would it hold true in production?
Currently I am trying to stay clear from S3 or any other third party CDN's to keep a low budget, and also trying to stay clear from storing files into Mongo.
Thanks for any and all opinions!
What about setting up a shared folder or NFS folder, have your Meteor app handle the file upload, write the file to that location, and configure Nginx or whatever you are using as the load balancer to serve those files. If you worry about browser refreshed when the file is put into the public folder, you do not need to write files to the public folder right?
There is plenty of documentation out there for looking up what content DB a site collection uses in SharePoint. However, I'm looking for the reverse. I have a specific DB, and I need to know where (what URL's) it's content is referenced or displayed.
We have a DB that has been partially corrupted and in need of restoring. It appears the only clean backup we have of it is relatively old. However, at first glance the library we know to be using it is lightly used. There has been no new content added to it since our backup was taken.
I am looking for a way to confirm that restoring from this backup wont unknowingly overwrite some critical data somewhere else.
In doing more digging, I did find another SO post that was able to get me the information I needed.
How to see all site collections in a specific content DB
-ContentDatabase contentdbname | select url, #{label="Size";Expression={$_.usage.storage}}
In navigating to the returned URL, I found recently added data. So that now rules out the restore.
So, far in our application, the *.js files were served directly from apache. For example, this was a script include in a jsp page : /foo/v6565/my_script.js. The v6565 in the path is phony and an internal apache redirect, redirects /foo/v6565/my_script.js to /foo/my_script.js.
Whenever my_script.js is updated, v<xxxx> in the included jsp page (an internal tool does it based on the SVN revision of my_script) is updated - thus forcing the browser to fetch my_script.js again and not the cached version. I hope I am able to explain my current approach clearly.
[A different approach could have been to user /foo/my_script.js?v=5652. However, there was some caching issue (can't remember it) because of which the decision was taken to use /foo/v56564/ instead of adding version to the queryParam. I will dig into it, though]
Now, that we are moving all of our *.js files to an s3 bucket, I was wondering what would be a way of doing this?
The path from s3 bucket would look like : mybucket.aws.com/js/my_script.js. How to I insert the version tag + redirection for s3? Are there any other standard approaches used when resources are served from s3?
(I've read about page redirects on s3 resources but the redirects are to be written directly on the resources, which is not really applicable in my case)
Thanks.
I think cache busting with ?v=<hash> is pretty much standard now.
It has been disadvised, however that's a pretty old resource (though often cited) and I'm not sure if this is still true. Even your trusted StackOverflow is using it with SHA1, so I guess it's good enough for everybody now.
I am currently trying to download a small binary file from the web, in order to upload that to another website, both using the API.
Previous versions seemed to have the "file" API module for such purposes, but I can't see anything similar as of the latest (1.14).
The file to be downloaded would be saved in some form of cache (browser cache, preferably), its path stored somewhere, to be then uploaded to another URL via POST.
How would I go about it, when the process should happen completely in the background?
I checked out the how to download a file page, but can't figure out where to download.
Is there a variable URI for the "Downloads" directory, and does a regular Add-On has write privileges in it?.
This is important, because the add-on must be able to function properly on various platforms.
You can use the pref, browser.download.lastDir, which should work for windows/mac as it will be saved in the OS format. However the pref may not always be set if the person has never downloaded anything before. In that case you'll have to build the directory yourself.
var dir = require("sdk/preferences/service").get('browser.download.lastDir');
To build the directory yourself you're going to have to go a little deeper. Check this article on MDN about File I/O which has examples. The DfltDwnld key should give you the directory you want.
Your add-on will have write permissions to everything Firefox has write permission to.