Re: rsyncing files that might change
At 23:09 31.10.2007 -0400, Matt McCutchen wrote: On Thu, 2007-11-01 at 10:35 +1000, Franc Carter wrote: If am rsyncing a file and I have the the following sequence of events happen in the same second 1. rsync starts 2. rsync sends some chunk of data to the other end 3 a local process modifies the chunk that has just been sent So, my question - is this case a race condition in which a subsequent run of rsync may miss that the file has been modified and hence skip it ? Unfortunately, yes. Shouldn't that be caught by the fact that the source file has a new (or at least different) time stamp now? bye Fabi -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsyncing files that might change
On 11/1/07, Fabian Cenedese [EMAIL PROTECTED] wrote: At 23:09 31.10.2007 -0400, Matt McCutchen wrote: On Thu, 2007-11-01 at 10:35 +1000, Franc Carter wrote: If am rsyncing a file and I have the the following sequence of events happen in the same second 1. rsync starts 2. rsync sends some chunk of data to the other end 3 a local process modifies the chunk that has just been sent So, my question - is this case a race condition in which a subsequent run of rsync may miss that the file has been modified and hence skip it ? Unfortunately, yes. Shouldn't that be caught by the fact that the source file has a new (or at least different) time stamp now? Sorry, I should have given a clearer example. All in one second 1. a process modifies the file and hence updates the source timesatmp 2. rsync starts 3. rsync sends the first chunk of data 4. a process modified the chunk that has been sent, but because it is in the same second there is no visible change to the timestamp bye Fabi -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html -- Franc -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsyncing files that might change
On 11/1/07, Matt McCutchen [EMAIL PROTECTED] wrote: On Thu, 2007-11-01 at 10:35 +1000, Franc Carter wrote: If am rsyncing a file and I have the the following sequence of events happen in the same second 1. rsync starts 2. rsync sends some chunk of data to the other end 3 a local process modifies the chunk that has just been sent So, my question - is this case a race condition in which a subsequent run of rsync may miss that the file has been modified and hence skip it ? Unfortunately, yes. Ok, thanks. Matt -- Franc -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsyncing files that might change
Franc Carter wrote: Unfortunately, yes. Shouldn't that be caught by the fact that the source file has a new (or at least different) time stamp now? Sorry, I should have given a clearer example. All in one second 1. a process modifies the file and hence updates the source timesatmp 2. rsync starts 3. rsync sends the first chunk of data 4. a process modified the chunk that has been sent, but because it is in the same second there is no visible change to the timestamp bye Fabi If this is a real problem, you might try a filesystem and OS version which supports microsecond or nanosecond timestamps. There's still no guarantee that changes are detected, but it's more likely. Oh, and I'm not sure if rsync reads the sub-second timestamps yet :-) -- Jamie -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
rsyncing files that might change
Hi, I hope I have not been google-incompetant, but I have been unable to find an explicit answer a case I am concerned about. If am rsyncing a file and I have the the following sequence of events happen in the same second 1. rsync starts 2. rsync sends some chunk of data to the other end 3 a local process modifies the chunk that has just been sent I have seen statements that rsync does a whole file checksum once the transfer is complete - but I couldn't find an explicit statement of whether this checksum is computed after the transfer has completed. So, my question - is this case a race condition in which a subsequent run of rsync may miss that the file has been modified and hence skip it ? thanks -- Franc -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
RE: rsyncing files that might change
Flames/Cluestick invited if I've got this wrong. I would expect: rsync checks blocks on source to see if they are the same. blocks which seemed to be the same (past tense) are not sent. blocks which seemed to be different will be sent with whatever the current content of the block happens to be. there is no check at the end to see that nothing changed in the interim. There MIGHT be something about file changed during transfer --- but some things big long messy --- you do what you can with what you've got. Hi, I hope I have not been google-incompetant, but I have been unable to find an explicit answer a case I am concerned about. If am rsyncing a file and I have the the following sequence of events happen in the same second 1. rsync starts 2. rsync sends some chunk of data to the other end 3 a local process modifies the chunk that has just been sent I have seen statements that rsync does a whole file checksum once the transfer is complete - but I couldn't find an explicit statement of whether this checksum is computed after the transfer has completed. So, my question - is this case a race condition in which a subsequent run of rsync may miss that the file has been modified and hence skip it ? thanks -- Franc -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsyncing files that might change
On Thu, 2007-11-01 at 10:35 +1000, Franc Carter wrote: If am rsyncing a file and I have the the following sequence of events happen in the same second 1. rsync starts 2. rsync sends some chunk of data to the other end 3 a local process modifies the chunk that has just been sent So, my question - is this case a race condition in which a subsequent run of rsync may miss that the file has been modified and hence skip it ? Unfortunately, yes. Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 1529] 32bit rollover problem rsyncing files greater than 4GB in size
https://bugzilla.samba.org/show_bug.cgi?id=1529 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 01:36 --- Sorry, Wayne you are right 2^32+1 really is 1. :) Yes 2^60 seems much to big to be practicable today but maybe, to avoid problems in the future, it would be better to have all this type-clean. BTW, AFAICR int overflows for signed types depend on the compiler and are not standardized. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 1529] 32bit rollover problem rsyncing files greater than 4GB in size
https://bugzilla.samba.org/show_bug.cgi?id=1529 --- Additional Comments From [EMAIL PROTECTED] 2005-09-06 06:37 --- Now when len is OFF_T is it possible that sum-count (which is size_t) in sum_sizes_sqroot() will rollover too at line: sum-count = (len + (blength - 1)) / blength; ? When we assume all variables have all bits set: 2^64 + (2^32 - 1) / 2^32 = 2^32 + 1 But sum-count can only represent 2^32 and thereofre sum-count will be 0. Did I made a mistake here? -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 1529] 32bit rollover problem rsyncing files greater than 4GB in size
https://bugzilla.samba.org/show_bug.cgi?id=1529 --- Additional Comments From [EMAIL PROTECTED] 2005-09-06 11:10 --- (In reply to comment #8) Did I made a mistake here? I have some minor quibbles with what you stated (which I will describe below), but, as you point out, this value can theoretically overflow. However, for the overflow to happen the file must be nearly an exbibyte in size (over a billion GiB), and anyone who is trying to rsync anywhere near that large of a file will experience rsync grinding to a halt due to the hash collisions in its checksum search algorithm (which will happen long before reaching rsync's maximum file-size limit). So, yes -- that value could theoretically overflow, but is not likely that it will in actual practice. As promised (threatened?? :-) ), I'll point out my quibbles with your logic, just for completeness: If we just ignore that 2^32+1 really would truncate to 1 instead of 0, the remaining problems are due to size differences from the variables in the latest rsync, which may stem from you looking at an older version of the source: - len is an int64 whose maximum positive value is 2^63 - 1. - blength has an enforced upper bound of 2^29. - count is an int32 whose maximum positive value is 2^31 - 1. The program logic as written (adding blength - 1 to the length) could cause a signed value to overflow into the negative when it is near its limit, so, let's pretend the code is written like this (which it probably will be soon*): sum-remainder = len % blength; sum-count = len / blength + (sum-remainder != 0); OK. That makes the maximum result prior to truncation: (2^63-1) / (2^29) + 1 = 2^34 As noted before, this is larger than the 2^31 - 1 value that count can hold. I calculate that the maximum file size is therefore (2^31-1) * 2^29, or 1,152,921,504,069,976,064 bytes (or slightly less than 2^60, which is an exbibyte). * The reason I will probably change this to avoid the potential overflow of adding (blength-1) is that rsync allows itself to be compiled on a system that does not have 64-bit integers, which means that the len value might really be an int32, and we don't want the length to be able to overflow into negative values. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 1529] 32bit rollover problem rsyncing files greater than 4GB in size
https://bugzilla.samba.org/show_bug.cgi?id=1529
--- Additional Comments From [EMAIL PROTECTED] 2005-09-06 11:38 ---
[EMAIL PROTECTED]:~ cat rsync-intoverflowtest.c
#include limits.h
#include stdio.h
int main(void)
{
unsigned i = UINT_MAX;
printf(i = %u, i+1 = %u\n, i, i+1);
exit(0);
}
[EMAIL PROTECTED]:~ ./rsync-intoverflowtest
i = 4294967295, i+1 = 0
[EMAIL PROTECTED]:~
Yes, I looked at an older version (just the one we ship with our enterprise
server :).
I'll have a look at the rest of your comment tomorrow. :)
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug, or are watching the QA contact.
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Rsyncing files
I want to to an Rsync with 4 servers.I want to sync the passwd and shadow. But I only want to do certain records to sync. basically all the user info. Is there away that this can be done? or do I have to do the whole file? thank you Ryan Holowaychuk Owner - HGIlive www.hgilive.com 250-371-1459 Secretary - Rotary Club of Kamloops Aurora Director - British Columbia Printing Imaging Association (interior Chair) -- Outgoing mail is certified Virus Free. Checked by AVG Anti-Virus (http://www.grisoft.com). Version: 7.0.280 / Virus Database: 264.12.4 - Release Date: 10/27/2004 -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Rsyncing files
On Thu 28 Oct 2004, Ryan Holowaychuk wrote: I want to to an Rsync with 4 servers. I want to sync the passwd and shadow. But I only want to do certain records to sync. basically all the user info. Is there away that this can be done? or do I have to do the whole file? Rsync handles data per file, it has no concept of records or such. I suggest you make some other way of generating the passwd and shadow files from different input files (system entries and user entries), so that you can transfer the files with just the user records. Paul Slootman -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 1529] 32bit rollover problem rsyncing files greater than 4GB in size
https://bugzilla.samba.org/show_bug.cgi?id=1529 --- Additional Comments From [EMAIL PROTECTED] 2004-07-31 03:48 --- I was getting bitten by the same bug, im my case a 4.1GB file rolling over in 100MBs. I've applied the patch and the problem in generate_and_send_sums is indeed fixed, but it appears to have just moved onto another much graver bug which causes nothing to get transfered: rsync rsync.planetmirror.com::fedora/linux/core/test/2.90/i386/iso/FC3-test1-i386-DVD.iso -azvvv . opening tcp connection to rsync.planetmirror.com port 873 Welcome to PlanetMirror's rsync service. You can find a web front end to this archive at: http://planetmirror.com You can also access this service via FTP at ftp://ftp.planetmirror.com If you are a regular PM user, please consider supporting PM by subscribing to a Premium or PremiumDownload account via the web front end. receiving file list ... recv_file_name(FC3-test1-i386-DVD.iso) received 1 names done recv_file_list done get_local_name count=1 . recv_files(1) starting generator starting pid=2243 count=1 delta transmission enabled recv_generator(FC3-test1-i386-DVD.iso,0) generating and sending sums for 0 count=66400 rem=4729 blength=66384 s2length=4 flength=4407835945 generate_files phase=1 recv_files(FC3-test1-i386-DVD.iso) FC3-test1-i386-DVD.iso recv mapped FC3-test1-i386-DVD.iso of size 4407835945 rsync: connection unexpectedly closed (89 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(359) _exit_cleanup(code=12, file=io.c, line=359): about to call exit(12) rsync: connection unexpectedly closed (69 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(359) _exit_cleanup(code=12, file=io.c, line=359): about to call exit(12) (In reply to comment #1) Your bug report made the problem easy to find. I've checked in a fix to CVS, but you can fix your current source by changing the size_t to OFF_T in the generate_and_send_sums() function in generator.c. It should look like this: static void generate_and_send_sums(struct map_struct *buf, OFF_T len, int f_out) Then, recompile, install, and the problem should be gone. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 1529] 32bit rollover problem rsyncing files greater than 4GB in size
https://bugzilla.samba.org/show_bug.cgi?id=1529 --- Additional Comments From [EMAIL PROTECTED] 2004-07-31 09:43 --- (In reply to comment #2) I was getting bitten by the same bug, im my case a 4.1GB file rolling over in 100MBs. I've applied the patch and the problem in generate_and_send_sums is indeed fixed, but it appears to have just moved onto another much graver bug which causes nothing to get transfered: Keep in mind, BOTH ends of the rsync connection need to apply this fix in order to work correctly, since both ends call generate_and_send_sums() to decide what needs to be transferred. So unless you've also gotten planetmirror.com to apply this fix to their rsync server, you will still have related rollover problems. This is probably what is causing your problem. Evan -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 1529] 32bit rollover problem rsyncing files greater than 4GB in size
https://bugzilla.samba.org/show_bug.cgi?id=1529 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-07-31 12:18 --- Keep in mind, BOTH ends of the rsync connection need to apply this fix in order to work correctly Only the receiving side calls generate_and_send_sums(), so only the receiver is affected by this fix. As long as Ludi is just pulling files, it shouldn't matter if their rsync is patched or not. I'm going to do some testing and determine if I need to reopen the bug. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 1529] 32bit rollover problem rsyncing files greater than 4GB in size
https://bugzilla.samba.org/show_bug.cgi?id=1529 --- Additional Comments From [EMAIL PROTECTED] 2004-07-31 12:42 --- I was under the impression that both sides needed it, because after I patched one end, it still didn't work for me, but after I patched both ends, it did. But maybe I screwed up something in the test. Evan -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 1529] 32bit rollover problem rsyncing files greater than 4GB in size
https://bugzilla.samba.org/show_bug.cgi?id=1529 --- Additional Comments From [EMAIL PROTECTED] 2004-08-01 13:45 --- (In reply to comment #2) I've applied the patch and the problem in generate_and_send_sums is indeed fixed, but it appears to have just moved onto another much graver bug which causes nothing to get transfered: I too saw an error trying to copy that file from planetmirror.com when I have a 4GB basis file on the receiving system, but it is the rsync daemon on the planetmirror.com server that is going away, so the only way to see what is wrong is to ask someone at that site to look in the rsync log and see if there are any errors. I tried a similar copy from two local rsync daemons (one running 2.6.2 and one running CVS), and neither one exhibited this failure, so it may be some kind of a resource problem on the planetmirror server (e.g. perhaps the daemon exceeded the ulimit memory limit). -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 1529] New: 32bit rollover problem rsyncing files greater than 4GB in size
https://bugzilla.samba.org/show_bug.cgi?id=1529 Summary: 32bit rollover problem rsyncing files greater than 4GB in size Product: rsync Version: 2.6.2 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] Tested and discovered between two machines with fairly recently updated debian unstable running rsync 2.6.2-2. I've been trying to rsync a large 7gig file across a slow network connection during off-peak hours, and came across a nasty bug in rsync relating to 32-bit rollover of the file size. I was restarting the rsync every night, and killing it every morning, and expected to eventually get the whole file. But much to my surprise, it never did seem to get anywhere, though when it was restarted, it seemed to be working fine. Unless the started rsync is allowed to complete the data transfer of all data past 4gig in a single run, rsync will never be able to complete this transfer. A verbose output of the start of a test rsync that makes the problem apparent follows: rsync -avvvP --bwlimit=30 test2:bigtestfile ./ opening connection using ssh test2 rsync --server --sender -vvvlogDtpr --bwlimit=30 --partial . bigtestfile receiving file list ... server_sender starting pid=22545 [sender] make_file(bigtestfile,*,2) [sender] expand file_list to 131072 bytes, did move recv_file_name(bigtestfile) received 1 names 1 file to consider recv_file_list done get_local_name count=1 ./ recv_files(1) starting generator starting pid=25013 count=1 delta transmission enabled recv_generator(bigtestfile,0) send_file_list done send_files starting generating and sending sums for 0 count=56894 rem=56488 blength=56888 s2length=4 flength=3236585472 Killed by signal 2. The interesting thing is that the actual file size on both ends is 7531552768, but the size claimed by rsync is exactly 4gig less than that, which is also the remainder of the size that fits in a 32bit unsigned int, which looks like a 32bit rollover or var size error. I will happily provide any further information or try fixes. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 1529] 32bit rollover problem rsyncing files greater than 4GB in size
https://bugzilla.samba.org/show_bug.cgi?id=1529 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-07-14 09:55 --- Your bug report made the problem easy to find. I've checked in a fix to CVS, but you can fix your current source by changing the size_t to OFF_T in the generate_and_send_sums() function in generator.c. It should look like this: static void generate_and_send_sums(struct map_struct *buf, OFF_T len, int f_out) Then, recompile, install, and the problem should be gone. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
rsyncing files in flash
HI all, I wonder how rsync works when files-to-be-updated are in flash (e.g. on IPAQ) Ideally rsync should write to the flash as little as possible (because of max reflash count) SO ideally the following should happen If file needs to be updated, the new file is created. Then the old file is deleted the new file is renamed to the old file (making sure that the file does not get copied over) Is this what happens ? W -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsyncing files in flash
2003-02-25T11:25:29 wim delvaux: I wonder how rsync works when files-to-be-updated are in flash (e.g. on IPAQ) Same thing that happens anywhere, as long as the flash is presented as a filesystem with POSIX semantics to a platform where rsync can run. I use rsync for automatic backups of Memory Stick flash cards routinely. Ideally rsync should write to the flash as little as possible (because of max reflash count) To the best of my knowlege, that was a quite minor issue with the first generation of flash media, and has since been engineered entirely out of existence, with a combination of newer flash media enjoying far greater numbers of permitted write cycles, and low-level hardware controllers automatically cycling blocks about to spread out hot spots. I'm pretty sure limited-number-of-writes is no longer expected to limit the life of flash media in practice; it'll keep working until it's so obsolete that you throw it away. My old 10MB PCMCIA Type II Flash card isn't very interesting with all my devices supporting the (far cheaper and smaller) 128MB memory sticks, for instance. If file needs to be updated, the new file is created. Then the old file is deleted the new file is renamed to the old file (making sure that the file does not get copied over) Is this what happens ? That's in fact exactly how rsync behaves, congrats! -Bennett pgp0.pgp Description: PGP signature -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
rsyncing files larger then 2gb (problem resolve)...
Dear Folks or the rsync club, Just to inform some of you who may have read my problem report about rsyncing files larger then 2gb. I'm happy to inform you all that the upgrade from 2.3.1 to 2.4.6, has resolved the problem of rsyncing files larger then 2gb and up to a 5.7gb as tested. This was performed in a Solaris 2.6 environment. So, some of you who had to remain on Solaris 2.6 for some particular reason, will not necessary have to upgrade to Solaris 7 or 8 it appears. We have up- graded to Solaris 8 afterwards, and it appears that nothing has changed regarding rsync, as we con- sidered the 32 bit kernel switch to 64 bit kernel. I want to thank some of you who responded to our temporary problem as it existed. Sincerely, Andre Quintana Server Operations Manager Vestek Systems, Inc.
