Related
What's the best way to check whether a given netCDF file exists in Fortran90? I have a Fortran program which simulates several systems and stores the data in a NETCDF file, and I'd like to be able to set it up so that I can run the code with already-existing netCDF files and just append the extra data.
It seems to work with the following:
status = nf90_open(filePath, NF90_WRITE, netcdfID)
if (status /= nf90_noerr) then
new_status = nf90_create(filePath, NF90_NETCDF4, netcdfID)
! setup
else
! check file has correct dimensions etc
end if
But I'd like to be able to be specific about the error, but the documentation isn't very specific about what the error code is when the file already exists.
I've also considered checking the status of the nf90_create(...) call, but I don't know how to specify cmode=NF90_NETCDF4 and cmode=NF90_NOCLOBBER at the same time.
To be honest, when I use NetCDF with Fortran and need to look at the documentation, I look at the C-documentation at https://www.unidata.ucar.edu/software/netcdf/docs/modules.html and 'translate' it to the Fortran API (for example replacing the nc_ with nf90_) because the C documentation is far more current than the Fortran one.
There seem to be these possible status results:
NF90_NOERR No error.
NF90_EPERM Attempting to create a netCDF file in a directory where you do not have permission to open files.
NF90_ENFILE Too many files open
NF90_ENOMEM Out of memory.
NF90_EHDFERR HDF5 error. (NetCDF-4 files only.)
NF90_EDIMMETA Error in netCDF-4 dimension metadata. (NetCDF-4 files only.)
None of these suggest that you were opening a file that doesn't exist. Maybe try it out?
But if you only want to know whether the file already exists, why not use Fortran's INQUIRE statement?
logical :: fileExists
...
inquire(file=filePath, exist=fileExists)
if (fileExists) then
call nf90_open(
else
call nf90_create(
end if
C/C++ rename function can be used to rename a directory.
Assume below situation (for Linux)
Directory X has files A, B and C.
X is renamed to Y (using C/C++ rename function). While the operation is in progress Server/Disk's power goes out. Then it is restarted.
Now is there a possibility of few files being in a directory X while others in Y.
e.g.
X : B
Y : A, C
Rename is only changing a name. The "id" of the file, and in linux a directory is a file which contains the "links" to other files and directories, stays the same!
As a file system is always directly relying to the physical block storage on any kind of hardware, always the complete block where the label is stored, must be rewritten and linked in the file system structure.
If a power fail happens in between, the "directory file" can be corrupted. This means, that more than the single renaming operations is involved!
BUT:
Modern file systems have many options to detect and repair such situations. E.G. ext4 has a journal in background. If any access may be interrupted, the journal has the information that these operation has started but not completed. By mounting such a partition/fs, the repair takes place automatically. If this is not possible, a fschk can do that job.
The situation, that only "some files" have been moved, is definitely never possible, because renaming a directory is not creating a new directory and moving the file names/links to the node id into the new directory, it is only a new name for an existing directory.
As a user: Simply use modern file systems and mostly all power down failures can be recovered by restart. You may find your filesystem in the "old" or the "new" version, but not in between.
It depends on implementation but for all file systems I know renaming is just replacing a label. So renaming of a directory doesn't differ from file rename operation.
And when you rename a file and turn off power you never end up with two files X and Y each having half of the file content.
I use boost log by this config.
[Sinks.2]
Filter="%Severity% >= 2"
Destination=TextFile
AutoFlush=true
Format="[%TimeStamp%] [%ThreadID%] <%Severity%> %Message%"
Asynchronous=false
Target="logs"
FileName="logs/quo.%Y%m%dT%H%M%S.%a.%5N.log.detail"
RotationTimePoint="00:00:00"
RotationSize=104857600
MinFreeSpace=4294967296
MaxSize=4294967296
ScanForFiles=All
when date change to next day. my program crash by exception:
terminate called after throwing an instance of
'boost::filesystem::filesystem_error'
what(): boost::filesystem::last_write_time: No such file or directory: "/root/work/hy-trade/bin/debug/logs/quo.20181027T173106.Sat.00000.log.detail"
I check my disk space, find the free space less than MinFreeSpace in config and the file quo.20181027T173106.Sat.00000.log.detail not exists.
how to avoid this exception?
version of boost is 1.67
thank you
It looks like someone had already deleted the log file before it was rotated. It may have been an external process, or Boost.Log.
With Boost.Log, this can happen if you have multiple file sinks that write log files into the same directory, which is also used as the target directory for the rotated files (i.e. the FileName parameter includes the path specified in the Target parameter, and there are multiple sinks that use that path). The problem is because, according to ScanForFiles=All, the library scans the target directory for any files but does not update the file counter to be used for creating new files. This means that if the file "quo.20181027T173106.Sat.00000.log.detail" was present in that directory when your process started then it would be considered as an old file, even if upon starting your process would be still writing new logs to that file. Then, when a file rotation happens and storage limits are exceeded (e.g. if MinFreeSpace is not satisfied), that file may be deleted. The rotation has to happen on another sink that still stores files into the same "logs" directory.
To solve the problem you can do one of the following:
Use ScanForFiles=Matching in your settings so that the file counter is updated after scanning. This will make sure that new log files have unique names and don't get deleted prematurely.
Write log files to a different directory from your target storage. I.e. specify FileName so that it doesn't point to the same directory as Target.
Also, you may want to add exception handling to avoid crashing in case of errors (which may still happen for whatever reason on filesystem operations). See here and here for more info (also, follow the links in those sections).
i when run this test program create the below error.
import shutil
src=r"G:\aaa"
dst=r"F:\zzz"
shutil.copytree(src,dst, symlinks=False, ignore=None)
FileExistsError: [WinError 183] Cannot create a file when that file already exists:
but the the folder of F:\zzz is empty!!!
shutil.copytree(src, dst, symlinks=False, ignore=None, copy_function=copy2, ignore_dangling_symlinks=False, dirs_exist_ok=False)
dirs_exist_ok dictates whether to raise an exception in case dst or any missing parent directory already exists.
Python 3.8 now have support of dirs_exist_ok parameter. This won't give that error anymore and overwrite the destination folder in case it already exists.
Hence you need to use:
shutil.copytree(src, dst, dirs_exist_ok=True)
"Cannot create a file when that file already exists" is a generic Windows message which is confusing because it's the same for directories or regular files. (Windows isn't known for very helpful error messages, you have to make do with that)
from the online help of shutil.copytree:
>>> help(shutil.copytree)
Help on function copytree in module shutil:
copytree(src, dst, symlinks=False, ignore=None, copy_function=, ignore_dangling_symlinks=False)
Recursively copy a directory tree.
The destination directory must not already exist.
So first time it probably works, but other times you need to perform
shutil.rmtree(dst)
to remove the destination directory prior to copying the tree (note that Windows is annoying with permissions and that files with read-only attribute can choke shutil.rmtree, which I personally copied the code into a custom version (you're encouraged to do so in the online help) to add a os.chmod(path,0o777) prior to deleting regular files.
I have reinstalled emacs 24.2.50 on a new linux host and started a new dotEmacs config based on magnars emacs configuration. Since I have used CEDET to some success in my previous workflow I started configuring it. However, there is some strange behaviour whenever I load a C++ source file.
[This Part Is Solved]
As expected, semantic parses all included files (and during the initial setup parses all files specified by the semantic-add-system-include variables), but it prints this an error message that goes like this:
WARNING: semantic-find-file-noselect called for /usr/include/c++/4.7/vector while in set-auto-mode for /usr/include/c++/4.7/vector. You should call the responsible function into 'mode-local-init-hook'.
In the above example the error is printed for the STL vector but a corresponding error message is printed for every file included by the one I'm visiting and any subsequent includes. As a result it takes quite a long time to finish and unfortunately the process is repeated any type I open a new buffer.
[This Problem Is Solved Too]
Furthermore it looks like the parsing doesn't really work as when I place the point above a non-c primitive type (i.e. not int,double,float, etc) instead of printing the type's definition in the modeline an error message like
Idle Service Error semantic-idle-local-symbol-highlight-idle-function: "#<buffer DEPFETResolutionAnalysis.cc> - Wrong type argument: stringp, (((0) \"IndexMap\"))"
Idle Service Error semantic-idle-summary-idle-function: "#<buffer DEPFETResolutionAnalysis.cc> - Wrong type argument: stringp, ((\"fXBetween\" 0 nil nil))"
where DEPFETResolutionAnalysis.cc is the file & buffer I'm currently editing and IndexMap and fXBetween are types defined in files included by the file I'm editing/some file included by the file I'm editing.
I have not tested any further features of CEDET/semantic as the problem is pretty annoying. My cedet config can be found here.
EDIT: With the help of Alex Ott I kinda solved the first problem. It was due to my horrible cedet initialisation. See his first answer for the proper way to configure CEDET!
There still remains the problem with the Idle Service Error (which, when enabling global-semantic-idle-local-symbol-highlight-mode, occurs permanently, not only when checking the definition of the type at point).
And there is the new problem of how to disable the site-wise init file(s).
EDIT2: I have executed semantic-debug-idle-function in a buffer where the problem occurs and it produces a ~700kb [sic!] output. It looks like it is performing some operations on a data container which, by the looks of it, contains information on all the symbols defined in the files parsed. As I have parsed a rather large package (~20Mb source files) this table is rather large. Can semantic handle a database that large or is this impossible and the reason of my problem?
EDIT3: Deleting the content of ~/.semanticdb and reparsing all includes did the trick. I still need to disable the site-wise init files but as this is not related to CEDET I will close this question (the question related to the site-wise init files can be found here).
You need to change your init file so it will perform loading of CEDET only once, not in the hook that will be called for each .h/.hpp/.c/.cpp files. You can change this config as the base, and read more in following article.
The problem that you have is caused because Semantic is trying to analyze header files, and when it tries to open them, then its initialization routines are called again, and again...
The first problem was solved by correctly configuring CEDET which is discribed on Alex Ott's homepage. His answer solves this first problem. The config file specified in his answer is a great start for a nice config; I have used the very same to config CEDET for my needs.
The second problem vanished once I updated CEDET from 1.1 to the bazaar (repository) version, which is explained here and in Alex' article. Additionaly one must delete the content of the directory ~/.semanticdb (which contains the semantic database and was corrupted I guess).
I'd like to thank Alex Ott for his help and sticking with me throughout my journey to the solution :)