When I create a directory using sytem user (vin.txt is my file)
create directory emp_dir1
AS "'C:\Documents and Settings\Administrator\Desktop\vin.txt'";
it creates it.
When I do the same using user Scott it gives an error for path of file that
"Identifier is too long"
but when I put this file path in single quotes instead of double quotes for scott, it creates it.
What is the reason behind?
A couple of things concern me about your question.
Firstly, regular users such as SCOTT should not be creating directories. The CREATE ANY DIRECTORY is extremely powerful, because it confers read/write privileges on any OS directory which is accessible to the oracle account; this is a massive security hole.
Secondly, the directory path must be just the path, without a file. We create files using UTL_FILE, Data Pump or whatever. A call to UTL_FILE.FOPEN() will fail if the passed DIRECTORY is actually a path to a file not an OS directory.
I cannot explain why the same statement executed successfully by SYSTEM fails when executed by SCOTT. I don't have 9i to hand, so I cannot test it. Please cut'n'paste the whole SQL*Plus output so that we can see what happens. As Peter has noted, your question appeared to contain a typo, so at the moment we cannot be certain that what you think is happening actually is what is happening.
Why are you using double-qoutes?
Strings in Oracle have single quotes, while double quotes can be used around column- and table-names.
I tried it using Oracle 10.2 (don't have any 9g around), and I can't reproduce this. It's never working, no matter what user I use.
When the string is as long as yours, I always get
ORA-00972: identifier is too long
When I try a shorter path (CREATE DIRECTORY emp_dir1 As "C:\vin.txt";) I get
ORA-01780: string literal required
Related
The following script works, but I need help with one change. Right now using lday serach, and a little utility called GETPASS, this script will pull a listy users, from a specified context out of an LDAP directory, compare their LDAP password, to an unused attribute, If different, add it to the unused attribute called carLicense, and then send it in SHA 1 format, up our google APPS domain, with Google Apps directory sync. The one problem, is that it when it returns the ldapsearch, it works fine with a user in this format:
cn=joebloe,ou=googletest,o=someorg
However, if the usename has a space in it like this:
cn=joe bloe,ou=googletest,o=someorg
the script will fail as it does not know how to deal with that space. In this situations, a single quote, around the DN will solve the issue IE:
'cn=joe blow,ou=googletest,o=someorg'
However, I have tried to alter the script to address this need of mine, and I am failing miserably, please see a copy of the script in Pasetebin below. Any help with be deeply and GREATLY appreciated, as this is currently my only stumbling block to success.
http://pastebin.com/htWxsNXj
Replace the first line of generating result file (in your pasting is line 66) with:
echo "dn: '$RESULT'" >> $SCRIPTPATH/gadspwsync.ldif
If it won't help, don't remove the file in line 75. Check the content, show us the first line, then show the expected content.
In one of the PL/SQL packages in our Oracle database, there's a global variable, g_file_path, that points to a location on the system where certain files will be stored:
create or replace
PACKAGE xyz_package
AS
...
g_file_path VARCHAR2 (80) := '/usr/tmp';
...
This variable is used in various UTL_FILE operations throughout the package.
Unfortunately, the path chosen is inadequate, and I need to figure out how to set a path dynamically depending on the environment where the database is running, e.g. so the path becomes /opt/ENVDB/xyz, where ENVDB changes depending on the env.
One idea is to emulate the behavior of the shell script:
>echo $XYZ_DB_TOP
That points to a suitable folder where the files can be stored. I can't think of a suitable PL/SQL function that emulates this behavior though. Any smart/simple solution to this problem? Any help is appreciated!
If you're using Oracle 9i or higher you should use a directory object instead. This is safer, because it only permits complete paths (no wildcards). It also doesn't require a database restart, unlike using UTL_FILE_DIR in the init.ora file. And it is far more secure because we can grant privileges on each directory to specific individual users.
But the aspect that will interest you the most right now is the that the abstraction of the directory object makes it a cinch to change the actual OS path, so it can be different in each environment. Just like this:
alter directory temp_data as '/home/oracle/tmp';
Find out more.
Does anyone know a pure Win32 solution for renaming a file and only changing its capitalization, that does not involve intermediate renaming to a different name or special privileges (e.g. backup, restore).
Since the Win32 subsystem generally regards two file names differing only in capitalization as the same, I haven't been able to find any solution to the problem.
A test program I made with the MoveFile API seems to work. So does the rename command in cmd.exe. What have you tried, and what error are you getting?
This isn't relevant, but further testing shows that renaming a long filename in this way works but will change the short filename (alternating between ~1 and ~2 for example), incidentally.
Just use the normal MoveFile API. That call probably just turns into ZwSetInformationFile(..., FileRenameInformation,...) The docs for FILE_RENAME_INFORMATION states that you need DELETE access and the file can't be locked etc, but those restrictions will probably apply to other solutions also.
I do not believe there is a way to expose two files with identical names that differ only in spelling to the Win32 subsystem. Even if some how you were able to create these files, the most likely result would be that only one file would be accessible - defeating the purpose of staying soley in Win32.
If you want to go into the Native layer, you can create a file with NtCreateFile and InitializeObjectAttributes w/o OBJ_CASE_INSENSITIVE or you can pad the end with extra spaces (if you pad with extra spaces, the file will not be accessible from Win32 dos paths). See here: http://www.osronline.com/ddkx/kmarch/k109_66uq.htm . I'm pretty sure you were already aware but I included it incase you did not know.
So long as your file is not immediately needed by another program, you can use my solution.
When you rename the file, capitalize, and delete the last letter. Then rename again and return the letter.
:)
I need to get a safe temp folder where I could store temporary files for my application, but so far my research has lead me to conclusion that all approaches I've found are flawed.
The first idea was to use GetTempPath function, but that causes two problems:
The folder might not exist, so I would have to truncate folders one by one up to root, and recreate them if they do not exist back to full path (error prone, tedious)
From "Larry Osterman's WebLog" click it seems that GetTempPath might fallback to USERPROFILE or Windows directory and extract whole lot of files right in there, which is SUPER BAD(TM)!
In the same post, there is a suggestion to use GetEnvironmentVariable, but this seems a dangerous function to me (missing TMP & TEMP envvars for instance).
Is there a cleaner function I could use? Seems that SHGetKnownFolderPath has no clue what temp folder is.
Your program is probably not the only one to rely on GetTempPath, so it's reasonable to expect it to return a proper writable path. Especially since Windows automatically initializes the TMP and TEMP environment variables for you; someone would have to go to some trouble to override them, and it would be their responsibility to make sure the change did not mess up their system.
I would go ahead and assume GetTempPath works properly, and worry about failures when you try to create the temporary file - there are other errors that might occur at that time that you need to check for anyway.
An idea would be to get the path where your application is (GetModuleFileNameEx combined with GetModuleHandle(NULL) and GetCurrentProcess) since this directory cannot be deleted under windows as long as your application is running from it (maybe I'm wrong ...some years ago I couldn't do this :) ) and in this directory create a temporary directory.
Your first bullet point is the solution. Wrap it up in a method so that you don't duplicate code.
According to this answer, Boost's Filesystem library can be used for this.
If I wanted to create a string which is guaranteed not to represent a filename, I could put one of the following characters in it on Windows:
\ / : * ? | < >
e.g.
this-is-a-filename.png
?this-is-not.png
Is there any way to identify a string as 'not possibly a file' on Linux?
There are almost no restrictions - apart from '/' and '\0', you're allowed to use anything. However, some people think it's not a good idea to allow this much flexibility.
An empty string is the only truly invalid path name on Linux, which may work for you if you need only one invalid name. You could also use a string like "///foo", which would not be a canonical path name, although it could refer to a file ("/foo"). Another possibility would be something like "/dev/null/foo", since /dev/null has a POSIX-defined non-directory meaning. If you only need strings that could not refer to a regular file you could use "/" or ".", since those are always directories.
Technically it's not invalid but files with dash(-) at the beginning of their name will put you in a lot of troubles. It's because it has conflicts with command arguments.
I personally find that a lot of the time the problem is not Linux but the applications one is using on Linux.
Take for example Amarok. Recently I noticed that certain artists I had copied from my Windows machine where not appearing in the library. I check and confirmed that the files were there and then I noticed that certain characters in the folder names (Named for the artist) were represented with a weird-looking square rather than an actual character.
In a shell terminal the filenames look even stranger: /Music/Albums/Einst$'\374'rzende\ Neubauten is an example of how strange.
While these files were definitely there, Amarok could not see them for some reason. I was able to use some shell trickery to rename them to sane versions which I could then re-name with ASCII-only characters using Musicbrainz Picard. Unfortunately, Picard was also unable to open the files until I renamed them, hence the need for a shell script.
Overall this a a tricky area and it seems to get very thorny if you are trying to synchronise a music collection between Windows and Linux wherein certain folder or file names contain funky characters.
The safest thing to do is stick to ASCII-only filenames.