VirtualBox

Ticket #3712 (closed defect: fixed)

Opened 5 years ago

Last modified 3 years ago

shared folders: copy shorter file don't change the file length

Reported by: meah Owned by:
Priority: major Component: shared folders
Version: VirtualBox 2.2.0 Keywords:
Cc: Guest type: Windows
Host type: Linux

Description

If a shorter file was copied from the guest to the host with a larger file with the same file name then the "new" file contains the new content of the shorter file and the old content of the rest of the larger file. The creation of a new file works fine.

The attached files show the result of the copy of the same file but _old was changed to _new and after 3_new the file was cut.

Attachments

att.zip Download (8.3 KB) - added by meah 5 years ago.
contains 3 files
copy_test.zip Download (15.5 KB) - added by meah 5 years ago.
VBox.log.bz2 Download (9.9 KB) - added by meah 5 years ago.

Change History

Changed 5 years ago by meah

contains 3 files

comment:1 Changed 5 years ago by meah

This behavior happens also in the older versions!

comment:2 Changed 5 years ago by Lelik

You mean fixed in 2.2.2?

comment:3 Changed 5 years ago by meah

no - i tried this - but it wasn't fixed - same behavior. Host: fedora 9 Guest: W2K

comment:4 Changed 5 years ago by Lelik

Unable to reproduce it here. Tried to copy by 'copy' and cut/paste. Can you describe it more detailed please? What file manager did you use to reproduce etc.

comment:5 Changed 5 years ago by meah

I tried it to reproduce it - with the cmd.exe and totalcommander 6.03. I logged this with the filemon-tool from sysinternals.

First i created 2 files with different lengths:

txt3.txt 38 Bytes:

eins zwei drei vier fuenf sechs

same in HEX-Format:

65696E730D0A 7A7765690D0A 647265690D0A 766965720D0A 6675656E660D0A 73656368730D0A

txt4.txt 33 Bytes:

eins zwei drei vier

sechs

same in HEX-Format:

65696E730D0A 7A7765690D0A 647265690D0A 766965720D0A 0D0A 73656368730D0A


First try with cmd.exe:

Y:\tmp>ver Microsoft Windows 2000 [Version 5.00.2195]

Y:\tmp>dir 06.06.2009 11:04 33 txt4.txt 06.06.2009 11:04 38 txt3.txt

Y:\tmp>copy txt4.txt txt5.txt

1 Datei(en) kopiert.

--> Filemon-log: cmd_copy_txt4_to_txt5_new.log

Y:\tmp>dir 06.06.2009 11:15 33 txt5.txt 06.06.2009 11:04 33 txt4.txt 06.06.2009 11:04 38 txt3.txt

Y:\tmp>copy txt4.txt txt5.txt txt5.txt überschreiben? (Ja/Nein/Alle): j Falscher Parameter.

0 Datei(en) kopiert.

Y:\tmp>dir 06.06.2009 11:04 33 txt4.txt 06.06.2009 11:04 38 txt3.txt

--> Filemon-log: cmd_copy_txt4_to_txt5_exists.log

RESULT: with CMD it is not possible to perfom a (copy to / replace) of an existing file.


cmd.exe on local directories (normal behaviour)

filemon-log: cmd_copy_local.log


Second try with totalcmd.exe:

begin: both txt3.txt and txt4.txt

  1. copy txt3.txt (38 bytes) to txt5.txt (38 bytes)

--> filemon-log: totalcmd_copy_txt3_to_txt5_new.log

  1. copy txt4.txt (33 bytes) to txt5.txt (38 Bytes)

--> filemon-log: totalcmd_copy_txt4_to_txt5_exists_is bigger.log

RESULT:

  • after copy file length is still 38 Bytes
  • the first bytes were overwritten by txt4.txt
  • the last 5 bytes contains the old bytes from txt3.txt

txt5.txt contains:

eins zwei drei vier

sechs chs

same as hex:

65696E730D0A 7A7765690D0A 647265690D0A 766965720D0A 0D0A 73656368730D0A 6368730D0A

--> the reduce of the filesize is only possible by deleting the txt5.txt and to reperform the file operation --> copy from a samller file to a bigger file is a problem (this is needed if you make a backup of a directory - but if you have changed files with smaller file length then you have a corrupt backup :(


third try: totalcmd with compatibility mode for Y:\

same behaviour like cmd.exe! no copy is possible -> error: write protection

The help file pointed out that the compatibility mode uses CopyFileEx.

filemon-log: totalcmd_in_compatibility_mode.LOG


try with notepad.exe/ultraedit.exe/hexworkshop.exe

works fine!

--> filemon-log: notepad_edit.log / hexworkshop.log

The attached zip-file contains the filemon-logs

I have also an strace.log - is this secure for publishing into the www? ;)

Changed 5 years ago by meah

comment:6 Changed 5 years ago by sunlover

Thanks for the detailed information. We are looking at this issue.

comment:7 Changed 5 years ago by sunlover

  • Priority changed from critical to major

Still could not reproduce the problem here. Both TotalCommander and cmd.exe works. Linux and Windows 32 and 64 bits hosts. However we did not try a fedora9 host.

Please attach VBox.log file of your W2K VM.

comment:8 Changed 5 years ago by meah

hmm - what's the difference?

This behaviour also happens also on an ubuntu 9.04-host 32-bit host (fully different hardware): Linux tralala 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux

I will try it onto other machines.

Changed 5 years ago by meah

comment:9 Changed 5 years ago by sunlover

Thanks for the log. Could you also tell me what is the version of the system32/drivers/VBoxSF.sys file in the guest?

comment:10 Changed 5 years ago by meah

Version of VBoxSF.sys: 2.2.4.47978

comment:11 Changed 5 years ago by meah

updates in Ticket #2592

comment:12 Changed 5 years ago by sunlover

Do you see this behaviour also with other guests (Windows XP, W2K with another service pack)?

comment:13 Changed 5 years ago by meah

With XPSP2 on another PC with VB 2.2.4 normal behaviour (without VT-X). With VT-X i don't try this, because on this machine (RHEL 4 x86_64) #3833 occures.

comment:14 Changed 5 years ago by meah

Last evening i installed a fresh version of w2k

The problem is the personal firewall zonealarm (last version). Without the installed! programm it works - with the installed programm it doesn't work. Same behaviour on W2kSP4 and XPSP2.

I tried to use a packet sniffer, but no traffic between host and vm available :( I didn't look in the OSE Source how it works.

I tried to conmmunicate with another SMB host an this works fine.

Is this a defect of the VBoxAdds or a defect of Zonealarm? I believe you can simply reproduce this issue.

comment:15 Changed 5 years ago by martin_frb

I had not seen this bug at the time of my report #4771

Likely the same, but I supplied a very short c example to trigger the issue.

BTW, I do not use zone alarm

comment:16 Changed 4 years ago by frank

Still relevant for VBox 3.1.2?

comment:17 Changed 3 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

No response, closing.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use