On Tue, Jun 12, 2018 at 11:51 AM Edward Thomson
wrote:
>
> On Tue, Jun 12, 2018 at 09:13:54AM +0300, Orgad Shaneh wrote:
> > Some of my colleagues use an ancient version of Source Insight, which also
> > locks files for write.
>
> If that application is locking files for writing (that is to say,
On Tue, Jun 12, 2018 at 09:13:54AM +0300, Orgad Shaneh wrote:
> Some of my colleagues use an ancient version of Source Insight, which also
> locks files for write.
If that application is locking files for writing (that is to say, it did
not specify the `FILE_SHARE_WRITE` bit in the sharing modes
+Cc: Orgad Shaneh
On Mon, Jun 11, 2018 at 08:35:41PM +, Edward Thomson wrote:
> On Sun, Jun 10, 2018 at 09:44:45PM +0200, Clemens Buchacher wrote:
> >
> > It is safe to do this on Linux file systems, even if open file handles
> > still exist, because unlink only removes the directory
On Sun, Jun 10, 2018 at 09:44:45PM +0200, Clemens Buchacher wrote:
>
> It is safe to do this on Linux file systems, even if open file handles
> still exist, because unlink only removes the directory reference to the
> file. On Windows, however, a file cannot be deleted until all handles to
> it
On Mon, Jun 11, 2018 at 11:02:42AM -0700, Junio C Hamano wrote:
>
> Aside from us not having to worry about emulating the umask, another
> reason why we prefer "create, complete the write, and then finally
> rename" over "overwrite and let it fail in the middle" is that the
> former makes sure we
"brian m. carlson" writes:
>> +file prevent creating new files at the same path. Note that Git will not
>> +update read/write permissions according to umask.
>
> I'm wondering if it's worth a mention that running out of disk space (or
> quota) will cause data to be truncated.
Aside from
On Sun, Jun 10 2018, Clemens Buchacher wrote:
> When replacing files with new content during checkout, we do not write
> to them in-place. Instead we unlink and re-create the files in order to
> let the system figure out ownership and permissions for the new file,
> taking umask into account.
>
On Mon, Jun 11, 2018 at 02:04:11AM +, brian m. carlson wrote:
> On Sun, Jun 10, 2018 at 09:44:45PM +0200, Clemens Buchacher wrote:
> > + file prevent creating new files at the same path. Note that Git will not
> > + update read/write permissions according to umask.
>
> I'm wondering if
On Sun, Jun 10, 2018 at 09:44:45PM +0200, Clemens Buchacher wrote:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index b6cb997164..17af0fe163 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -923,6 +923,14 @@ core.sparseCheckout::
> Enable
When replacing files with new content during checkout, we do not write
to them in-place. Instead we unlink and re-create the files in order to
let the system figure out ownership and permissions for the new file,
taking umask into account.
It is safe to do this on Linux file systems, even if open
10 matches
Mail list logo
