What happen if we try to create a file on a unmounted folder?
Does the file is created on local system?
I have a mounted folder that could sometimes unmount for reasons
I'm going to schedule a oracle procedure that writes a file inside there, what will happen if somehow the folder is unmounted
Does the file is created on local system?
Yes. Or, better, the file is created into that directory (don't call folder unix directories... :)), wherever that directory is (it could be part of a mounted remote file system, in that case it was not part of the local system).
Writing permissions on the directory play a role, and the mount command can also play with those permissions, but this is another, complicated matter.
Related
I have a directory on the computer having many files and sometimes I need to sync it with a clone from a device.
I use rsync.
Rsync does not see when a file was renamed or moved in other directory and it is very slow sometimes.
Is there a smart syncing tool that can see when a file was renamed/moved in the main directory and just rename on the clone without physical remove+copy ?
I want to do that:
When I use a tortoise svn and create a folder then commit it; Server creates a link for the folder automatically.
This is a system which I dont know how it works.
I Create a folder = "document"
Commit it to a server. Some pc in the local office.
Then when I write a "http://server/Folders/Doc/"; I see the entire folder.
Do you know how can I build a system like that?
How to check if a file is being referenced by any symlinks in the directory - I want to delete all the other files except the symlink and the refernced file. Is there any direct command to check or a work around to do so?
If the symbolic link is in the same directory or in a well known one, that would be easy. Just check if no other file share the same inode ls -d1Li.
Otherwise, there is no direct way to know if a symbolic link exist to any given file. Even exploring all mounted file systems wouldn't be reliable, as the link might exist on a currently unmounted filesystem, or on a remote machine accessing the file remotely (NFS, CIFS and the likes).
i'm new to Berkeley db, i have installed the version "db-4.8.30.NC.tar.gz" but now i would like to find the configuration
information by using the configuration file.
I've read in the documentations that this file is named DB_CONFIG and it exists in the
database home directory.
In my system, i have uzipped the tar file under /usr/db-4.8.30.NC but i still haven't found
the DB_CONFIG file.
Well, i'm trying to find where the DB_CONFIG file is located in Unix, but i can't find it.
May you please help me?
Thanks, in advance
You (or a system administrator) writes the DB_CONFIG file by hand to modify any of the DB_ENV environment variables that can be over-ridden at runtime.
The DB_CONFIG file is stored in the db_home directory; the docs/programmer_reference/env_naming.html file has full details, but you can either pass an explicit db_home parameter in the DB_ENV->open() call or rely on the DB_HOME environment variable to locate the DB_CONFIG file, if any exists. The environment variable approach might be nice if the system administrator would reasonably want to move the storage around as they wish; the specific path name approach might be nice if you don't want to bother your system administrators with details of managing your storage.
I have a small Perl-based CGI application, which I am running in the project web space provided for a SourceForge project. This application stores data in a SQLite (v. 3) database file.
When I run test scripts from a shell, I can read from and write to this SQLite file. However, when the CGI code is executed by Apache, it has read-only access. Write operations result in a log file error:
error.log.web-2:[Wed Oct 27 14:40:22 2010] [error] [client 127.0.0.1] DBD::SQLite::db do failed: unable to open database file
For testing purposes, I have cranked the permissions for that SQLite file all the way up to 777. No difference.
However, there are some funny caveats to SourceForge's project web space, and I wonder if I'm being tripped up by that. Generally, the main web server filesystem is read-only to Apache. If you have files that need to be writable at runtime, you're supposed to store them in a special "persistent" directory elsewhere... and create symlinks from your web space to the actual files under that directory.
I have done this, and the permissions are set to 777 for both the symlink and the actual SQLite file under the "persistence" location. I know this mechanism works in general, because I'm doing the same thing with cache and log files and it works there.
I'm wondering if there's anything funky about SQLite itself, along the lines of it not wanting to open a symlink (rather than a raw file) for writing.
I believe the answer to this question is that it can't be done. Further research into SQLite tells me that the driver must get a lock on the database file before it can do any write operations. This type of lock cannot be obtained when the actual file is on a different machine with its filesystem cross-mounted.
I believe this is the case with SourceForge project web space hosting. It looks like the (writable) "persistent" directory is actually on a totally separate machine from the read-only web server filesystem.
In short, if you stumble across this question because you're having the same issue... either look for different web space hosting, or else it may be time to re-work your app and step up to MySQL or some other DB (SourceForge gives you free MySQL hosting anyway).
Another issue is if you have permissions for the specific db file but you don't have permission to make the temporary files in the directory. (Mixed permissions, or too restrictive permissions)
https://www.sqlite.org/tempfiles.html
If you can't write the temporary files then you can't do any writes on a sqlite database file. If you switch it to a :memory: database you could get by or maybe use the pragma mentioned by #bob.faist PRAGMA temp_store = MEMORY, but really you should diagnosis and fix the permissions problem if possible.
Use these commands to see if you have permission to write in those file locations.
ls -l app.db
getfacl app.db
ls -l -d . # check the directory to see if you can write the temp files there
getfacl .
Use chmod or setfacl -m to fix the files or folders to let you write to them.
Also check your diskspace.
df -k
If it shows that your partition where the database file is located or is trying to write its files to are full, you could also get these kinds of issues.
Hope that helps.