If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Rate Thread | Display Modes |
Ads |
#17
|
|||
|
|||
Odd network behaviour
On Sun, 17 Sep 2017 17:52:51 -0500, VanguardLH wrote:
Disable the Recycle Bin (for that drive). When you Move, you also Delete. Move = Copy + Delete. Deleting with the Recycle Bin is a safety net that takes extra time. Instead of actually deleting the file from the file system (removing its file record which is very quick), the file gets moved into a holding folder (its file record gets updated which is also quick). As someone else pointed out, Move doesn't place the moved (deleted) file in the Recycle Bin. Entries in the Recycle Bin are removed in FILO (first in, last out) order. That is, the oldest entries get deleted to make room for a new entry. That description sounds like 'first in, FIRST out', or FIFO. -- Char Jackson |
#18
|
|||
|
|||
Odd network behaviour
Char Jackson wrote:
VanguardLH wrote: Disable the Recycle Bin (for that drive). When you Move, you also Delete. Move = Copy + Delete. Deleting with the Recycle Bin is a safety net that takes extra time. Instead of actually deleting the file from the file system (removing its file record which is very quick), the file gets moved into a holding folder (its file record gets updated which is also quick). As someone else pointed out, Move doesn't place the moved (deleted) file in the Recycle Bin. Then Move is even more dangerous than Paul exclaimed. What if the target is no longer available when you want to Undo Move? Where is Windows Explorer going to get a [hidden] copy of the file that has been deleted in the file system within the source partition (drive)? Is it going to hope that it can restore the file record that it just modified hoping that some other process hasn't already reused those clusters in the file system? I would've expected Undo Move to be better equipped than relying on some recovery tool (e.g., Piriform Recuva). |
#19
|
|||
|
|||
Odd network behaviour
In article , says...
pjp wrote: I thought I'd said, I watched it simply have dialog window disappear with no message and no sign any more activity was going on. I was doing nothing with the pc at the time, just watching it. It was like it thought it had completed it's task. Tried 2nd time with no issues. Sounds like there was a network connection hiccup so the transfer aborted. There are network monitors but you'd want one with a log so you could see if there was a network hiccup during the aborted file transfer. Does this happen a lot? From your description, looks like it was a one-time hiccup. Prior file transfers have worked. Were the source and target hosts within the same intranet or across the Internet? Anyone else using your network? Does anyone else have access to the shared folder? Is it a private share or do you allow external access? NetworkShareMonitor is a free and portable tool you can use to watch your shared folders. https://www.raymond.cc/blog/track-wh...shared-folder/ (other monitors are mentioned there) Are the 3 hosts you mention in a wired (Ethernet) intranet across a router but in the same subnet or are you using wifi and an AP (access point) to put these hosts on the same subnet? "Hiccup" is my quess also. Based upon maybe three "bad" copies in last year or so and immeditely after when tried again the copy did finish correctly that's my "best guess". I routinelky do the same thing almost daily in fact without issues, in fact 20Gb just before I posted this. |
|
Thread Tools | |
Display Modes | Rate This Thread |
|
|