EXIFTool can detect when the offset of tags is incorrect
[ExifTool] Warning : [minor] Possibly incorrect maker notes offsets (fix by 1060?)
see FAQ. Can we detect incorrect offsets with metadata-extractor and ideally fix them in the same way?
From https://exiftool.org/faq.html#Q15:
1) Use the -F option to allow ExifTool to attempt to fix the incorrect
offsets. If ExifTool was correct in its diagnosis, then this option
will fix the incorrect offsets. This is usually the appropriate choice
if this problem was caused by editing the image with other software.
Related
I'm trying to get used to Emacs, I'm coding in C for my school. So, I installed flycheck to check for potential compliation errors. However, I encounter several problems. Here's the message I get when I test flycheck with the c/c++-gcc checker : flycheck buffer
I have two issues there : - first, flycheck claims the checker "returned a 1 exit code without errors" depsite the fact it actually did, and it's even displaying it right after ! - secondly, it does not seem to be able to display quotes correctly, the only thing displayed are their unicode escape sequences.
I can't find out why those issues are present. Can anybody help me on this ?
fixed both my problems by setting my environment language to UTF-8.
This question already has answers here:
How can I view the C code after compilation in binary code?
(5 answers)
Closed 7 years ago.
I accidentally deleted my source program, now i only have the gcc compiled code.Is there any way to get back my source code.
Recovering C source from a binary has been described as "turning hamburger back into cows". You will not be able to recover your original source code. At best, you will get back some code that's functionally equivalent to your original source, but it won't contain any of your original variable names, comments, macros, etc., it may not be structured the same (depending on how aggressively it was optimized), and it may not be very understandable (again, depending on how it was optimized).
Hopefully the original is still recoverable somehow.
You can use a disassembler, but you'll never be able to fully restore the program's source code.
To prevent this in the future, I recommend either using source control, like Git or Subversion. Using these tools, you will always have backups of your code in case a big mistake like this were to happen.
If you are using an Eclipse-based IDE, it might have a saved version of your source in its history. If so, right-click on the project and select "Restore from Local History...".
EDIT
Otherwise try grep -a -C 200 -F 'Unique string in text file' /dev/sda1 > OutputFile; replace 200 with the number of lines you think are in the file and /dev/sda1 with the partition.
See the Text file recovery section at https://wiki.archlinux.org/index.php/File_recovery for more info.
Good luck!
In an attempt to add the include paths to Syntastic (3.6.0-106; Vim 7.3), to stop it from giving a fatal error at the first include it can't find, I tried creating a .syntastic_c_config file. There's not a lot of information on how this is supposed to work, but there are references out there and I followed their example:
-I/path/to/include
-I/you/get/the/idea
-L/some/library
-lfoo
-lbar
-DHAVE_SOME_FLAG
-pedantic
-Wall
-std=c99
That is, one compiler argument per line.
This has had the effect of removing virtually all error checking, unless I force it with :SynasticCheck -- at which point, it seems to work a little bit better, but not exactly how I'd expect. However, either way, if I :echo g:syntastic_c_config_file (or any other option that I'm expecting to be set), Vim just gives me an undefined variable warning.
I'm clearly doing something fundamentally wrong, but I'm not really sure what!
This is an old post, but I stumbled upon here searching for an answer to the same problem. Looks like Syntastic has changed quite a bit. Documentation listed above by OP is not valid anymore. Current (as of 18 July 2020) documentation is at: https://github.com/vim-syntastic/syntastic/blob/master/doc/syntastic-checkers.txt
To add include paths to 'gcc' checker, you would need to create a file with your include dirs, one per line, preceded by '-I'. For example, in /home/user/.syntastic_c_config_file add:
-I/usr/include/glib-2.0/include
-I/usr/include/boost
Then in your {vimrc} file (usually, ~/.vimrc), add one line:
let g:syntastic_c_config_file='/home/user/.syntastic_c_config_file'
Syntastic has become more powerful now and contains many options in the above linked documentation.
It turns out that Syntastic will source the configuration file without explicitly setting the respective variable. Moreover, the contents of the configuration file are not passed into any syntastic_c_* variables, but nonetheless passed into the call to gcc. Syntastic is also clever enough to backtrace to look for the configuration file (e.g., it will go up levels until it finds it, so you can keep the .syntastic_c_config in your project root).
As to why it was failing, the debug log was showing that my compiler was ignoring the library flags (-L/some/path and -lfoo) and that was blocking Syntastic from any further syntax checking. Removing those lines from my config file solved the problem.
I couldn't find anything on this, but probably its just because I don't know how to search, because i don't know how to call it.
I tried to compile some C-Code and got the following error:
/path/to/file.h:55:32: error: path/to/include.h: No such file or directory
I know the error and i know that the problem is in file.h at line 55 - where's an include, which doesn't exist.
But what does the 32 stand for?
Marty
It's the number of the character within line 55.
This might also be referred to as "column number" (see comment) but I find that slightly misleading, as e.g. a tab character will generally take up more than one column in your editor, but still count as only one character for the compiler.
I'm attempting to build Firefox on my Windows Vista Ultimate machine. I keep getting the following error:
nsinstall: Bad file number
I've read that this error is caused because of UAC in Vista. Here are the two articles that lead me to this conclusion. https://wiki.mozilla.org/Penelope_Developer_Page#Windows_Vista and http://www.kevinbrosnan.net/mozilla-build-error-nsinstall-bad-file-number
Using the standard "Run as Administrator", I've attempted to redo my build but I get the exact same error. I also started a normal command prompt as admin and then went to the batch file in mozilla-build (start-msvc8.bat) and ran it. Still, same error at the same point.
Any other insights on how I might either get around this error or perhaps something else is causing the error?
Note: I also posted something here in the hopes to get topic-specific help but I've not heard a peep... After I posted that I found the info on nsinstall. Anyway, I prefer SO so I thought I'd try here...
Update: I've attempted to completly disable UAC to correct the problem as is suggested by cnemelkasr. I've received the exact same error. This new knowledge is making me think that a file or folder is missing... Does anyone who has experience with NSInstall know what the given error -- Bad file number -- might mean? I figure it might be referring to a file handle...
If it really is a UAC error, you can try turning off UAC altogether. I've had to do this for several packages. There are numerous places on the web to get the instructions for doing that.
http://www.petri.co.il/disable_uac_in_windows_vista.htm is one of them.
I found the answer to my question. I'm posting the answer here to share the answer with others and to close this question.
After disabling the UAC, it was suggested that the directory depth was interfering with NSInstall. I moved the folder from c:/Users/Frank/Documents/hg-repos/firefox-src-hgRepo/mozilla-fv-expirement/ to C:/mozilla-fv-expirement/. Cleaned all previous build attempts and finally redid my build (with UAC off) and I received a working debug binary.
The suggestion was posted at: mozilla.dev.builds
The "Bad file number" message in the cases I have seen, is caused by too many arguments passed to execvp (command, argv) (or similar) function. But only from some programs. An old bash, sh or a Borland/Watcom program in your PATH is an likely candidate.
So when you shorten the name of the build directory, the total size of the command line (that eventually gets passed to CreateProcess()) gets shorter. I don't think UAC has anything to do with this since I've seen this on Win-XP too. But it's a bit strange Mozilla would not use relative paths while building. I guess it uses some directory prefix value in it's makefiles (I've never tried building it).
If you look at the documentation for _execvp():
http://msdn.microsoft.com/en-us/library/3xw6zy53.aspx
E2BIG is one of the possible errno values:
The space required for the arguments and environment settings exceeds 32 KB.
Now, here is the strange part.
Fact 1:
On Visual-C/MingW (any version), strerror(EBADF) doesn't return "Bad file number" .
(it return "Bad file descriptor").
Fact 2:
On Borland's CBuilder 5.6 and Watcom 1.9 (these do not use the MSVC runtime), strerror(EBADF) does indeed return "Bad file number".
Theory:
Is possible that Borland, Watcom (and other CRTs too?) mixes up the meaning of E2BIG and EBADF. Did that make any sense? Someone please correct me if you have a better theory.
I'm a bit confused myself...
Conclusion: Either shorten the size of your environment (easiest) or shorten the command-line (not always easy).
--gv