| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When saving a file by atomically renaming it to its final destination,
we fsync(2) the parent directory to make sure the new directory entry
is persisted. However, not all file systems support fsync on file
descriptors referring to directories. As a result the save operation
fails and subsequent attempts result in warnings regarding outdated file
content, even though the data has most likely been successfully written.
Ignoring this particular error seems fine, because it is a permanent
limitation of the file system and not a temporary failure.
Fixes #792
|
|
|
|
|
|
Instead of simply appending a tilde to the original file name, we now
create an unique temporary file based on the pattern `.filename.vis.XXXXXX`.
In case the file does not yet exist, we use 0666 & ~umask as permission,
(this should match the previous `open(2)` based behavior).
|
|
Fail atomic save if temporary file already exists. A follow up
commit will use `mkstemp(3)` for temporary file creation.
|
|
Otherwise this fails on macOS.
Fix #578
|
|
As currently implemented this does not properly integrate with
multiple cursor support. The functionality should be provided
in a layer higher up.
The jumplist and changelist need to be redesigned, for now they
are broken.
|
|
|
|
This is no longer needed because we always insert \n never \r\n.
|
|
|
|
Add casts to uintptr_t to avoid unrelated pointer comparisons.
|
|
|
|
Fix #536
|
|
|
|
Use something like dos2unix(1) and unix2dos(1), if you
need to edit such files.
|
|
|
|
These are generally implemented efficiently in libc.
While memrchr(3) is non-standard, it is a common extension.
If it is not available, we use a simple C implementation from musl.
|
|
|
|
|
|
At some point we might drop this mess and ask users to rely
upon dos2unix(1) and unix2dos(1), respectively.
|
|
vsnprintf fails
|
|
This was wrongly changed in commit 74085e92c095d0bf4b98e262cc07ccf9b7dfff3b.
|
|
If the user wants new files to be created as 600, they will have set
their umask to 077 in their environment. vis shouldn't restrict this
further than the user has configured.
|
|
POSIX says that
The mkstemp() function shall use the resulting pathname to create the
file, and obtain a file descriptor for it, as if by a call to:
open(pathname, O_RDWR|O_CREAT|O_EXCL, S_IRUSR|S_IWUSR)
So this umask change didn't do anything in practice, unless the original
umask was more restrictive than 0177.
|
|
|
|
|
|
Change the text_iterator_char_{prev,next} functions to treat
them as a single character, meaning cursor motions will skip
both bytes at the same time.
|
|
|
|
|
|
We now guarantee the existence of at least one non-sentinel
piece at all time and allow iterators to recover from these
delimiting pieces.
|
|
Unlike EOF address 0 needs no special treatment.
|
|
Handle zero length pieces gracefully. At some point
we should write a comprehensive set of unit tests
for the iterator API.
|
|
|
|
Technically this macro name is in the reserved namespace of errno.h.
The same is true for EPOS. Maybe we should rename them at some point,
but for now the short names are convenient.
Fix #443
Close #444
|
|
This should avoid undefined pointer comparisons.
|
|
This will be used for unit test purposes to force more allocations.
|
|
Work around for a (bogus?) tis-interpreter warning.
|
|
|
|
There are cases where it is useful to specify how the file should be saved.
|
|
Also rename underlying C code.
|
|
The new code is preferable because it works independently of the
variable type. Whereas before a change in type, but not within the
sizeof expression would cause a wrongly sized allocation.
|
|
|
|
s/Action/Revision/g
|
|
|
|
|
|
|
|
|
|
The default atomic save method using rename(2) would correctly fail,
but the calling code would wrongly assume it was because of dealing
with a special (e.g. hard or symlink) file or that some other properties
(e.g. POSIX ACL, SELinux labels, permissions etc) could not be restored.
It would then go on to ftruncate(2) the file, if the following writes
then fail (which is likely if the new file content is bigger or some
other process has used up disk space in the mean time) we lose data.
This should fix it for the common case i.e. regular file where the
rename(2) based method is used. The problem persits when directly
overwriting a file.
It is unclear whether this could be improved/fixed by:
1) first appending the new file content to the old one
2) fsync the data (old||new)
3) deleteing the original file content by overwritting it with
the previously appended new file content. That is essentially
moving the new file content from the end of the file to the start.
4) ftruncate to the new file size
5) fsync the data (new)
if during 1) or 2) an error would occur we could revert the operation
by doing a ftruncate to the original file size. An error in steps 3-5
would still be fatal.
Another option would be to first write a backup file somewhere.
|
|
|
|
Heap allocates a zero terminated string of the given range.
Freeing is the caller's responsibility.
Checks for unsigned integer overflow i.e. passing SIZE_MAX
as len will always fail because there is no room for the
terminating NUL byte. This is important as EPOS is defined
to be SIZE_MAX.
|
