In my local development environment (xampp, windows) I have the file
D:\Documents\repos\somerepo\public\img\bathroom\8\small\someimage.jpg
I try to delete it with:
Storage::delete(public_path('img/bathroom/8/small/someimage.jpg'));
However the file still exists after running the code.
When I print the path of public_path('img/bathroom/8/small/someimage.jpg') And copy it inside file explore it opens the file just fine.
How can I make laravel delete the file?
When I run:
if(File::exists($path)){
return $path." Does not exist";
}
Where path is public_path('img/bathroom/8/small/someimage.jpg') it tells me it does not exist.
Assuming you are using the default filesystem configuration, the public disk stores files in storage/app/public. The local disk uses storage/app. In short, both local disks manage files under storage/.
The public_path() helper returns the fully qualified path to the public directory. So:
public_path('img/bathroom/8/small/someimage.jpg')
will generate a path like this:
/your/project/public/img/bathroom/8/small/someimage.jpg
Note that this is not under storage/, where both Storage local disks operate. Passing Storage a fully qualified path outside the root of the filesystem it manages will not work.
To work with files outside the roots of the disks that Storage is configured for, you will have to use standard PHP functions like unlink(), etc. Alternatively, move the files you want to maintain with Storage into one of the disks it is configured for, add the symlink to make them visible, and update the references to those files in your views etc.
Related
I need to maintain a file system in mongo where I need directories to be created and file should be placed in the directory which i have created. So is there any in built functionality in python or how we can do that using GridFs?. So basically along with uploading the file i need to mention the directory where it needs to be placed
GridFS permits specifying the name of the file. You can put anything you like in there including a path where components are separated by slashes so that it looks like a filesystem path.
However, GridFS does not provide any facilities for hierarchical traversal of stored files (i.e. grouping files into directories). You'd have to implement that in your own application/library if you need this functionality.
I am importing data from a CSV file using the COPY FROM in PostgreSQL. It works flawlessly on my machine, however, were I to clone the repository onto a new machine the code would cease to function to the file path being hardcoded starting at the Users directory of the computer.
In other languages, I would be able to use something like ./ or ~/ to start somewhere not at the absolute beginning of the file, but I haven't found T-SQL or Postgres to have that functionality available.
What I have
COPY persons(name,address,email,phone)
FROM '/Users/admin/Development/practice/data/persons.csv
How can I make that file path function on any machine the project gets cloned to?
I am trying to use an environment variable in the odoo.conf
file to specify the path where the logs are stored.
So far I have tried:
logfile = ${test.rueda}/odoo.log
But it does not work.
Is there any way to achieve this?
The Odoo configuration files do not support access to environment variables.
I can think of 2 possible approaches:
Use relative paths. The file names in the configuration are relative to the working directory of the Odoo server process. Start the Odoo server in different directories, one for every purpose, and keep the same structure relative to that.
Use environment variables in the command line. When starting the Odoo server, any configuration option can be passed using -- (2 dash signs) as a prefix. In the start script, you can then use environment variables as in any other shell script.
See https://www.odoo.com/documentation/11.0/reference/cmdline.html for details.
For referencing files or path:
When i work without external disk (where i can find my datadir):
i use in odoo config file data_dir = my_absolute_path_in_my_local_disk.
This path have a symbolic redirection to where is my local physical location of my local data directory
When my external disk come back, i change the symbolic link:
my_absolute_path_in_my_local_disk -> my_external_disk_..._data
I'm looking for what best practice I should use when it comes to testing with Go using local files.
By using local files, I mean that in order to test functionality, the application needs some local files, as the application reads from these files frequently.
I'm not sure if I should write temporary files myself just before running the tests using the ioutil package tempdir and tempfile functions, or create a test folder like so;
testing/...test_files_here
main.go
main_test.go
and then read from the contents inside
testing/...
A folder named testdata is usually used for this purpose as it is ignored by the go tool (see go help packages).
This is my current test setup:
app/
main.go
main_test.go
main_testdata
package1/
package1.go
package1_test.go
package1_testdata1
package2/
package2.go
package2_test.go
package2_testdata1
All the test data that is specific to a single package, is placed within the directory of that package. Common test data that will be used by multiple packages are either placed in the application root or in $HOME.
This set up works for me. Its easy to change the data and test, without having to do extra typing:
vim package1_test_data1; go test app/package1
While learning how to create Lua file output code with the support of LÖVE, I've always hated that LÖVE filesystem handler always saved the specific file somewhere in C:/Documents and Settings/...
How can I create a code that saves a file into a specific folder that I'd like to define (and maybe to change while running the application)?
The love.filesystem library doesn't let you do anything outside the sandbox. However, LÖVE doesn't disable Lua's built in io library, so you can use io.open to open files outside the sandbox and read/write them as normal, as well as other Lua functions like require and loadfile.
It also doesn't restrict loading of external modules, so you can (for example) require "lfs" to load LuaFileSystem and use that, if it is installed.