From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from Ishtar.sc.tlinx.org (ishtar.tlinx.org [173.164.175.65]) by sourceware.org (Postfix) with ESMTPS id 566EC385C418 for ; Wed, 2 Feb 2022 17:10:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 566EC385C418 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tlinx.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tlinx.org Received: from [192.168.3.12] (Athenae [192.168.3.12]) by Ishtar.sc.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id 212H9NHI003175; Wed, 2 Feb 2022 09:09:25 -0800 Message-ID: <61FABACA.9070104@tlinx.org> Date: Wed, 02 Feb 2022 09:09:30 -0800 From: L A Walsh User-Agent: Thunderbird MIME-Version: 1.0 To: Adam Dinwoodie CC: cygwin@cygwin.com Subject: Re: Renaming (with 'mv') very large files is SLOW References: <25079.63376.349893.86395@consult.pretender> <25079.64935.73349.331715@consult.pretender> <20220131213615.l3bvoyacl3jcvls2@lucy.dinwoodie.org> In-Reply-To: <20220131213615.l3bvoyacl3jcvls2@lucy.dinwoodie.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 17:10:19 -0000 On 2022/01/31 13:36, Adam Dinwoodie wrote: > >> Could it be that the first 'mv' triggered an anti-virus read of the file since >> perhaps it detects it as a new/changed file? >> >> But if so, would 'mv' (under Task Manager) be showing the 100+ MB/s disk activity? >> > > That definitely seems plausible; there's a reason a significant number > of the applications that are known to interfere with Cygwin operation > (see [0]) are antivirus applications. But what would trigger your > antivirus to want to scan a file, and how much work is required to do > that, is something you'll need to take up with your antivirus vendor, > I'm afraid. > ---- Something that most people don't realize, is that windows always puts a lock on a file when it is going to READ it. It's an advisory lock, and usually, on a local file access, it can be removed by the user who started the read and it's not noticed. But if cygwin is accessing the file through some virtual table, Windows might think it is on a separate virtual device -- like an indexing scanner that indexes content, or anti-vir. This becomes real noticeable if it is a real remote file on a remote fs. In samba there's a setting to allow breaking advisory locks -- and if you are the only person who can be accessing that file, its best to allow them to be broken -- only real useful if you have multiple users (or programs) trying to modify the same file at the same time. If the oplocks are held by another process windows may return a 'file busy' so cygwin uses a file-copy method to 'move' the file. I usually only run into this locally when the file is opened by a system process when I try to modify it, like deleting a thumbs.db when explorer is updating it. The param in samba is "fake oplocks = yes", tells samba to fake oplocks and not really enforce them. It's a per-share parameter, so you need to set it on every share. But only on shares where you are the only 'modifier'. For actual shared-access w/other users -- only read-only access should be used. If you ever want to have local file caching of remote content work -- need to set the oplocks to fake or have the files be read-only. > [0]: https://cygwin.com/faq/faq.html#faq.using.bloda > >