The thing is that I have been working with breakpad recently and I have some issue generating the "FILE" data in the sym file.
In my sym file :
FILE 46 c:\users\soorya-pt2570\desktop\project files\crashanalyserbackend\breakpad\simulatecrash\project\source.cpp
The actual path to my source file :
"C:\Users\soorya-pt2570\Desktop\Project Files\CrashAnalyserBackend\BreakPad\SimulateCrash\project\Source.cpp"
as you can see, the path to my source file is converted to lowercase. Any Idea on what's going wrong?
I used the dump_syms.exe available here for my pdb file
The problem is that Windows file systems are usually case insensitive. For our internal use case I have a script that does a mapping of the file names from the case insensitive name that dump_sys.exe produces to the correct name. I'm not aware of any direct fix in breakpad itself. If you only handle the path on Windows it should actually not matter at all and you should not see any issues from the lower case file names.
Related
I have built a program in c++ whitch checks how many words a text has.
The text is stored in a .txt file in the same directory as my .exe file. I was wondering if there is a way to make the name of my .txt file irrelevant as long as the .txt file is in the same directory as my .exe file is? I would like to be able to change the name of the .txt file and still run my program successfully without getting a "error opening file" message.
You need to enumerate the files in your app's folder until you find one with a .txt file extension.
However, there is nothing in the standard C++ libraries to handle that.
You need to use platform-specific APIs 1 to determine the folder where your app is running from, and then you can use platform-specific APIs 2, or a 3rd party cross-platform API 3, to enumerate the files in that folder.
Once you discover the file, only then can you open it.
1: (like parsing the result of GetModuleFileName() on Windows)
2: (like FindFirstFile() and FindNextFile() on Windows)
3: (like boost::filesystem)
I have a c++ project that I would like to send to someone in executable form. The issue is the program must read from a .txt that I created (specific deliminators). Currently my program reads from a file path that is specific to my computer,
parseFile("/Users/David/Desktop/FinalProject/Store.txt");
How could I package the .txt file and the executable file together, where the exec. reads specifically from the that .txt on anyone's machine?
Note: I am using Xcode
Change your programs to receive 'file path' as a parameter. Write a note(ReadMe) with the program to specify the file format and added a sample data file with the package
tl;dr: if you just put the text file in the same folder with your executable, you can open it with parseFile("Store.txt");
In most runtime implementations, there is a notion of a "working directory." When you open up an executable via the graphical shell (by double clicking it or something to that effect) the working directory is the same as the directory the executable is in.
Now, if you try to open a file in your program via a path that isn't fully qualified, then the path that gets used will be relative to the working directory.
A fully qualified path is a discrete path that points to a single entity in your filesystem. "/Users/David/Desktop/FinalProject/Store.txt" is one such example, as it starts at root (/ on *nix, DriveLetter:\ on Windows) and says exactly which directories you need to traverse to get to your file.
A path that is not fully qualified (which basically means that it doesn't start at the root of your filesystem) can be used to perform relative file addressing. Most runtimes will assume that any path that is not fully qualified is meant to be relative to the working directory, which basically means that the path that actually gets opened is the result of concatenating your provided path to the end of the working directory.
As an example, if you opened your binary, which is stored as /Users/David/Desktop/FinalProject/a.exe, then the working directory would be set to /Users/David/Desktop/FinalProject/. If your program then tried to open "Store.txt", the runtime would see that you're trying to open a path that isn't fully qualified, so it would assume you meant to open a file relative to the working directory, which would then be /Users/David/Desktop/FinalProject/ + Store.txt, which would be /Users/David/Desktop/FinalProject/Store.txt.
The nice thing about this is that if you move your binary, the working directory moves too. if you move a.exe along with Store.txt to /Users/David/Desktop/FinalProject(copy)/, then when you open /Users/David/Desktop/FinalProject(copy)/a.exe, the working directory will be /Users/David/Desktop/FinalProject(copy)/ now, and now when you call parseFile("Store.txt"), it will instead open up /Users/David/Desktop/FinalProject(copy)/Store.txt. This holds true when moving to other computers, too.
It's worth noting that if your binary is run from a command line utility, the working directory will often be the directory the command line shell is in, rather than the executable's directory. It is, however, a part of the C standard that the first command line parameter to main() should be the name of the executable, and most implementations supply you with the fully qualified path. With some minimal parsing, you can use that to determine what path to use as a base for addressing files.
Is there any way so that i can get extension of a given file.
if suppose there is a file "abc.txt" but after renaming the file name is "abc.exe" now the extension is .exe is there any way that i can get the original extension of a file in which it was created.
I looked for GetFileInformationByHandle but that was not much of help
is there any way that i can get the original extension of a file in which it was created
No, not without any operating system add-ons or a simple backup of the file
.
I have an external USB, NTFS-formatted hard drive which contains many files which I need to eventually copy to a drive on a Windows Server 2008 R2 machine.
The files on the drive were placed there by scripts run with the drive mounted on Solaris. The user who did this copy was careless and edited their copy script on a Windows machine, resulting in shell script lines such as:
cp /sourceDir/sourceFileName /externalDrivePath/targetFileName\r\n
and as such, the files on the external drive have a trailing carriage return in their filenames. Standard Windows copy utilities (copy, xcopy, robocopy) fail to copy these files with error 0x7B / 123 : "The filename, directory name, or volume label syntax is incorrect."
I have tested, and am fairly sure that if I had the drive mounted again on a Linux box, I should be able to repair the files with commands such as:
mv /externalDrive/targetFileName\r /externalDrivePath/targetFileName\n
However, I do not have immediate access to a Linux machine.
What I have tried so far to repair/move these files:
"Application" solutions on Windows Server 2008 R2:
Renaming files in Windows Explorer -- would be unfeasible solution due to sheer volume of files, but it doesn't work anyways.
Wildcard pattern matching the filenames from cmd prompt, e.g. copy E:\externalDrivePath\targetFileName* anotherPath. Fails with 0x7B error.
Copying files from cmd prompt using 8.3 (short) filenames. Files in question do not have short names, per output of dir /x
"Programming" solutions on Windows Server 2008 R2:
Copying/Renaming files using Python/Java: any attempt to open/copy the carriage-return file throws exception tracing back to the same 0x7B Windows error.
Copying files using Windows C 'CopyFile' API: fails with 0x7B error. Here I found the files using FindNextFile API, and passed that source path into CopyFile, but the OS still fails to copy the file.
Writing my own file copy function in C using fopen, ofstream, etc. The fopen call again fails with 0x7B.
Copying files using C++ boost::filesystem APIs: fails with 0x7B error. Again, found the files using a boost::filesystem::directory_iterator and passed the found file's path to boost::filesystem::copy_file()
Providing file path to Win32 APIs CopyFile / MoveFile as "\?\E:\externalDrivePath\targetFileName\r". Calls fail again with 0x7B error.
I also dabbled with mounting this drive on an OS X machine to run the copy, expecting it would provide support for the NTFS drive more like Solaris did. However, it fails to copy with similar error messages to Windows -- I guess OS X's NTFS implementation is more "Windows-like"?
If this is solvable on Windows, I feel like it's going to either require a very low-level C function that manipulates the FILE itself, without 'opening' it based on its string filename. Not sure how to go about that. That, or some file repair utility that I'm unaware of which incorporates this functionality already.
Any alternative approaches or suggestions how to implement what I'm describing would be most appreciated.
TLDR: Try CreateFileW with a unicode path prefixed with \\?\ and containing the trailing carriage return.
The \\?\ path syntax bypasses a lot of the usual validation rules, unicode exansion, etc and allows long file paths and even (dangerously) allows characters like slashes inside a filename.
Given that, I'd imagine a carriage returns should be fairly trivial to handle...
This page relating to long filenames has more details. Relevant parts quoted below
There is no need to perform any Unicode normalization on path and file name strings for use by the Windows file I/O API functions because the file system treats path and file names as an opaque sequence of WCHARs. Any normalization that your application requires should be performed with this in mind, external of any calls to related Windows file I/O API functions.
When using an API to create a directory, the specified path cannot be so long that you cannot append an 8.3 file name (that is, the directory name cannot exceed MAX_PATH minus 12).
The shell and the file system have different requirements. It is possible to create a path with the Windows API that the shell user interface is not able to interpret properly.
And from here
On newer file systems, such as NTFS, ex-FAT, UDFS, and FAT32, Windows stores the long file names on disk in Unicode, which means that the original long file name is always preserved. This is true even if a long file name contains extended characters and regardless of the code page that is active during a disk read or write operation. The case of the file name is preserved, even when the file system is not case-sensitive ...
I had a similar problem in the mid 90ies, on Windows 3.11.
I ended up using rename from a C program (declared in <stdio.h>).
If that fails you could try low-level C system calls: open, read and write to copy the file to a new name.
Low-level calls usually bypass limitations imposed by user-friendly high-level functions.
I'm writing a program using Xcode for school that requires we use the open() system call. I do
int input_file_desc = open(input_path, O_RDONLY);
printf("input file desc %d:\n", input_file_desc);
and it comes up with a -1. The file's path is ~/data_to_read. I set up the command line arguments in xcode. input_path is a const char * that i get from the command line. For some reason it works fine if I change the filename and command line argument to ~/data_to_read.txt. Let me know if more info is needed. thanks.
EDIT: I only tried it with .txt to see if that was the problem, but I still don't know why it needs an extension in the first place. You can have files without an extension right? In which case it should still work, as long as neither the file path nor the argument has an extension, right?
It looks like you are using C, why the C++ tag then? is it allowed? there are easy and good classes in C++ to manipulate files.
However you definitely need to include the extension in the file name (the input_path) , as many files with the same name and different extensions can exist in the same directory, so which one should be opened?
EDIT: it should be known that file extensions are (especially in UNIX-Like OS) only a "helping" thing, they are not really essential. For Example, you could have a file that contains a C++ code but has no .cpp extension, for example its name is foo only with no extensions (or even has a crazy extension like foo.bar). Still you could use the g++ to compile it, because the extension is not really important as long as the content is valid for the application that uses that file.
The way I understand your question, you're asking if a file needs to have an extension to be opened by the C open function, right? The answer to that is no. C does no magic for you, and will attempt to open a file with the exact filename you have specified. If the file has an extension, you must specify it in the api, if not you should not.
Check the error code returned in the errno variable (use strerror or perror to get a human readable error message) to find out what is wrong. That should point you in the right direction.
As other said the extension is simply part of the name.
The problem you are experiencing is probably because your OS is windows and the guys at microsoft had this dead stupid idea of "hiding" the extensions by default so your file seems to be named "test" while indeed it's named "test.txt" because it was created with notepad.
On windows systems is also common to see files named "foo.txt.txt" because this totally dumb idea of hiding/showing/guessing/automatically-adding extensions doesn't work well at all.
You can set the preferences on your computer so that file extension is always shown and this is the best thing to do on a windows system. Even better if you are interested in programming you may consider to switch for programming to an environment like linux that is less hostile to programmers.
A filename doesn't need an extension -- a file can be called "data_to_read". But most filenames on your system do have extensions, it's just that Windows Explorer hides them from you. To open a file from a program, you need to specify this extension.
Right-click on a file in Windows Explorer and select "Properties" to find out whether a filename has an extension. Or look at the files in a Windows Command Prompt console.