I am new to c++. The problem i am facing is with CreateDirectory method.
CreateDirectory("\\ServerName\foldername\",NULL) gives no error but it also doesn't create any directory. However if I write "D:\foldername" instead of "\\ServerName\foldername\" it works perfectly fine.
Any help would be highly appreciable.
"\ServerName\foldername\" is not a valid Windows path
"\\ServerName\foldername\" is valid, but this is the name of the "foldername" share on the "ServerName" network host. This is still not a valid directory you can create.
If ServerName is a valid host name, and if sharename, is a valid share on that host, on which you have write rights, then you could create "\\ServerName\sharename\foldername". But you can't create "\\ServerName\foldername\"
Thanks to Matteo for pointing out that in C strings, the \ must be escaped to \\
You must understand the difference between Fully Qualified vs Relative Paths
For Windows API functions that manipulate files, file names can often be relative to the current directory, while some APIs require a fully qualified path. A file name is relative to the current directory if it does not begin with one of the following:
A UNC name of any format, which always start with two backslash
characters ("\")
A disk designator with a backslash, for example "C:\" or "d:\".
A single backslash, for example, "\directory" or "\file.txt". This is
also referred to as an absolute path.
for more Information refer Naming Files, Paths, and Namespaces
Related
Hi this may apply to platforms/wikis outside of xwiki, but I am trying the embed a file by doing the following
[[myfile>>file://C:/users/myfile.txt]]
where clicking on the newly created link does nothing.
I have tried with backslashed file path too but no difference and three slashes infront of "file:"
this should be pretty straightforward....
There should be three slashes in a URI like file:///C:/.
After the "protocol" part, the file URI scheme takes first a host name (which can be omitted in your case, because you are trying to access a local resource), then the path. Between host and path there is a slash. (This holds for other URI schemes, as well...)
The slash has to remain, even if the host part is omitted.
I have a little problem, I need to make directory from my c code or c++, doesn't matter.
But directory name must contain characters like ':', ' ','.' in general current time,
when I try to create with mkdir() function I get EINVAL error, but from system("mkdir ...") everything is ok.
How can I solve this problem?
Thank you!!!
Different filesystem formats have different rules about what is and is not a valid character. For ext2 and its descendants, A file name may contain any character except for '/' or '\0'.
For FAT filesystem and its descendants, the list of invalid characters is larger, and includes ':'.
Check to see what filesystem format you are using, and try running your program on a different filesystem.
I'm using the Windows API calls FindFirstFile and FindNextFile to search for files matching a certain wildcard string in a directory. For example, I might want to find all XML files in a directory, and so I search using the pattern "*.xml".
I'm running into the problem that if I'm searching for a 3-letter extension, and a file's extension starts with that 3-letter extension, it will get picked up by my search, even if the extension contains more characters after those first 3. For example, if my file is named somelongname.xmlaaaa, this will get picked up by the search for "*.xml". The short name of that file is somelo~1.xml, which matches my wildcard string.
I could do my own wildcard matching to get around this problem, but presumably a Windows API would be able to do this more efficiently than I could, and my code would be simpler. As far as I can tell there isn't a way to force these functions to ignore short names. Is there any API Windows exposes with this functionality?
Check out FindFirstFileEx - it has a fInfoLevelId parameter that takes a FINDEX_INFO_LEVELS enumeration:
typedef enum _FINDEX_INFO_LEVELS {
FindExInfoStandard,
FindExInfoBasic,
FindExInfoMaxInfoLevel
} FINDEX_INFO_LEVELS;
FindExInfoBasic
The FindFirstFileEx function does not query the short file name, improving overall enumeration speed. The data is returned in a WIN32_FIND_DATA structure, and the cAlternateFileName member is always a NULL string.
However:
Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP: This value is not supported until Windows Server 2008 R2 and Windows 7.
Unfortunately, the documentation JoeFish found in his answer turns out to be a little misleading. The search will still find files that match the short name, even if you pass in FindExInfoBasic. It just won't include the short file name in the cAlternateFileName member of the WIN32_FIND_DATA structure.
I did however find that there's a Windows function PathMatchSpec that will do the same wildcard matching against a supplied string. So, I was able to add a second step to my searching that verifies that the long name matches the pattern. It's even available in Windows XP.
In building a C++ project with the GNU tool chain, make tells me ~
src/Adapter_FS5HyDE.d:1: *** multiple target patterns. Stop.
Search, search, search, and I found out that make thinks that it has multiple targets because the path to my included headers has spaces in it. If you've got your headers stored in some sane place like C:\Program Files then you can take care of this by using the old DOS paths (e.g. C:\PROGRA~1). However, when you have your headers in a truly insane place like My Documents you can get around the problem with MY DOC~1 because there's still a space.
Any idea how to tell my compiler to look in My Documents for headers without make confusing the path as two objects?
(Note: Feel free to throw tomatoes at me for putting header files in My Documents if you'd like, but there is a little rationale for doing that which I don't feel like explaining. If the solution to this question is easy, I'd rather keep it the way it is.)
You can figure out what the old path is by doing a DIR /X in your command prompt.
Or, most of the time you can fake it with the first 6 characters - spaces + ~1 + extension (8.3 paths won't have spaces).
Or, you can use quotes: "C:\Documents and Settings\Administrator\My Documents".
I don't know about make specficially, but the normal way around this is to put quotes around the path i.e.
cd "C:\Program Files\"
does that work?
Side note: the short name (8.3) for the same folder might not be the same on different OS installations. Thus, you can't be sure that C:\Program Files will always be C:\PROGRA~1.
Short names can't contain spaces in them either, so the usual short name for My Documents is MYDOCU~1, not MY DOC~1.
You can find the exact short name for any folder or file (including My Documents) using dir /x <filename>.
If you are using the GNU toolchain from Windows command line (cmd.exe), you should be able to use quotes (") around the folder/file names to work around this problem.
For some folders, including My Documents, you can specify an alternative location. To do this, right-click the folder, select Properties, select Location tab, and away you go. I use this to put my downloads and music on another drive (D:).
Write a wrapper script (e.g. batchfile) to translate the path names to short form.
I have a script "runwin" that does stuff like this - instead of, e.g. gcc <args> I can call runwin gcc <args>;
runwin will make heuristic guesses as to which arguments are filename paths and translate them, then call gcc on the resulting string of arguments.
A user input string for a destination path can potentially contain spaces or other invalid characters.
Example: " C:\users\username\ \directoryname\ "
Note that this has whitespace on both sides of the path as well as an invalid folder name of just a space in the middle. Checking to see if it is an absolute path is insufficient because that only really handles the leading whitespace. Removing trailing whitespace is also insufficient because you're still left with the invalid space-for-folder-name in the middle.
How do i prove that the path is valid before I attempt to do anything with it?
The only way to "prove" the path is valid is to open it.
SHLWAPI provides a set of path functions which can be used to canonicalize the path or verify that a path seems to be valid. This can be useful to reject obviously bad paths but you still cannot trust that the path is valid without going through the file system.
With NTFS, I believe the path you give is actually valid (though Explorer may not allow you to create a directory with only a space.)
The Boost Filesystem library provides helpers to manipulate files, paths and so... Take a look at the simple ls example and the exists function.
I use GetFileAttributes for checking for existence. Works for both folders (look for the FILE_ATTRIBUTE_DIRECTORY flag in the returned value) and for files. I've done this for years, never had a problem.
If you don't want to open the file you can also use something like the access() function on POSIX-like platforms or _access() and friends on Windows. However, I like the Boost.Filesystem method Ricardo pointed out.