Odd network behaviour

pjp wrote:
In article , lid says...
pjp wrote:
I run a small in house network at home, usually only 3 pcs turned on.
One of them has a share setup that I store videos etc. in for a buddy
comes by and collects them onto a thumb drive.

Today I had about 16 avi files to copy onto that shared folder.
Proceeded as normal meaning I opened a windows for where the files were
and where I wanted a copy placed. Did the right click drag-n-drop and
choose Move. Sat back and watched it move three files and then dialog
box of transfer just disappeared without any error message or anything.

I could see two copies of the files being moved when/after it happened.
An incomplete copy on the shared folder and the original still in the
original folder. I reselected all and did the same right click but
choose Copy instead the second time. Everything went as expected.

Thing is, what happened the first attempt during the Move operation?
I've noticed the odd time before a bad copied file but this is the first
time I saw the transfer just abort without any message etc. Must you
always check before deleting the original just in case!!!
*Never ever* use Move

*Always* use Copy

It's safer to break the operation into two pieces.

And for cases where extra paranoia is involved, you have
the option of computing checksums on the source and destination
files, before deleting the source tree. Newer versions of 7ZIP
have a right-click entry for generating checksums or signatures.
A standalone tool would be hashdeep or md5deep, which can handle
a file tree for you. Those tools support multithreading,
but multithreading should only be used if your storage
device happens to be an SSD or an NVMe (zero seek time).
It's counterproductive to multithread with a hard drive
with those tools.

The fastest 7ZIP one, can compute a sum at 1500MB/sec.

Implementations of MD5 can manage 300MB/sec.

And SHA1 might be on the order of 100MB/sec.

Each of those options, trades speed for "potential for
signature collisions". MD5 is plenty good enough for
this purpose. You don't need SHA256 or whatever virustotal.com
uses this week for signature generation. A weaker check
is enough for a quick check.

TOO much bs to verify copied ok, Easier to just have buddy tell me later
he had some problem playing file and could I give him another copy. Less
time, no real stress so no brainer LOL. So long as my burned dvd copy
and external hard disk copy are ok ... LOL

I used to think like that too, until it turned out some
of my backups were ruined by the bad RAM.

You never know, until it hits you, how much damage
it has done.

A transfer that stops, without any feedback, is mighty
peculiar. Wouldn't you agree ?

Paul

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

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).

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.