croc truncates files when asked not to overwrite

[ryancdotorg]

croc truncates files when asked not to overwrite

[schollz]

great bug, will accept PR!

[ryancdotorg]

https://github.com/schollz/croc/blob/v10.0.6/src/croc/croc.go#L1806

c.recipientGetFileReady(finished)

This in turn calls

recipientInitializeFile which, if i chmod -w the file first, calls os.Create on line 1606, sets truncate = true on line 1616, and truncates the file on line 1619.

Perhaps you could do

					fmt.Fprintf(os.Stderr, "skipping '%s'", path.Join(fileInfo.FolderRemote, fileInfo.Name))
					c.FilesToTransfer[i] = nil
					continue

and then somehow filter the array?

I don't have time to grok the codebase and figure out how to fix it, and this actually destroyed data.

Meanwhile, you should update croc to cancel the entire transfer in this case so that others do not lose data.

[schollz]

hm. I think the error might have to do with your receiving file being zeros?

I can't replicate the error with random data on both sides:

Sender:

> dd if=/dev/urandom of=potato bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes (21 MB, 20 MiB) copied, 0.0649862 s, 323 MB/s
> sha256sum potato
9709dbad9dedac47da6c21825a01a75a3fdbead915d6af8ac930135b1e0cf66b  potato
> croc --version
croc version v10.0.6
> croc send potato
...
> sha256sum potato
9709dbad9dedac47da6c21825a01a75a3fdbead915d6af8ac930135b1e0cf66b  potato

Receiver:

> dd if=/dev/urandom of=potato bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes (21 MB, 20 MiB) copied, 0.0687534 s, 305 MB/s
> sha256sum potato
e498d7172011d7611dc5dcff9e5c55e559bb21a0b925a969ef2619766e0776a2  potato
> croc CODE
Accept 'potato' (20.0 MB)? (Y/n) y

Receiving (<-127.0.0.1:52242)

Overwrite 'potato'? (y/N) n
No files transferred.
> sha256sum potato
e498d7172011d7611dc5dcff9e5c55e559bb21a0b925a969ef2619766e0776a2  potato

In both cases, when the croc exits the Sender and Receiver both have files that have the exact same SHA-256 sum as before they ran the croc program...

this actually destroyed data.

I'm surprised, I can't replicate it using non-zero data. Can you share any more information?

[ryancdotorg]

The file being sent must be smaller than the file present on the receiver.

[ryancdotorg]

I did just verify this with random data on both sides.

[ryancdotorg]

The original incident involved a 3.2GB file called photos.zip on the receiving system and a 650MB photos.zip being sent. This was with croc 9.x, but I thought I should try to replicate it with the current version.

I tried to fix the bug, but my naive attempts either caused the transfer to abort or croc to hang. There seems to be some events and/or sender/receiver communication I don't understand.

[schollz]

thanks for clarifying. the fix was a silly mistake or degradation perhaps - that after finishing it needs to return, so one line change seems to fix it: https://github.com/schollz/croc/pull/724/files#diff-79c5691e97f5cb9a1a66c4386dc13c054b83f90debc2a704c72cc91ab0a0945bR1641

[schollz]

would you mind building from source and trying it out?

[ryancdotorg]

Works for me now, thanks!

The "skipping" message to stderr could use a \n, though.

[schollz]

Thanks, fixing in 10.0.7