Modified rename_object and put_headers to handle objects larger than
5GB. Files larger than 5GB are required to use the multi interface.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@363 df820570-a93a-0410-bd06-b72b767a4274
complete s3fs_readdir() refactor
- multi interface now batches HTTP requests
- proper HTTP KeepAlive sessions are back! (CURLOPT_FORBID_REUSE is no longer required)
- use xpath to quickly grab xml nodes
- lots of cleanup
- fixes some strange stat cache behavior
- huge readdir performance benefits (8-14x in my case) on large directories
git-svn-id: http://s3fs.googlecode.com/svn/trunk@348 df820570-a93a-0410-bd06-b72b767a4274
- fixed a bug in the file cache, it was attempting to set the mtime
on symlinks
- general code cleanup; moved some string functions to string_util.cpp
git-svn-id: http://s3fs.googlecode.com/svn/trunk@345 df820570-a93a-0410-bd06-b72b767a4274
- s3fs_flush() now checks to see whether the file on the remote end is the same as the local copy.
- md5sum() now requires a file descriptor instead of a path.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@322 df820570-a93a-0410-bd06-b72b767a4274
Functional changes are limited to the multipart upload process. Each uploaded part is now verified against a local md5sum.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@318 df820570-a93a-0410-bd06-b72b767a4274
Beginning of s3fs "utility" mode - initially -u option
just reports in progress multipart uploads for the
bucket. Eventually this mode could be used for
other S3 tasks not accessible through typical
file system operations
For multipart upload, use safer mkstemp() instead
of tmpnam() for temporary file
Increased the curl connect and readwrite timeouts
to 10 and 30 seconds respectively.
Autodetect when a big file is being uploaded,
increase the readwrite timeout to 120 seconds. This
was found through experimentation. When uploading
a big file, it is suspected that time is needed
for S3 to assemble the file before it is available
for access. It was found that when a large file
was uploaded via rsync, the final mtime and
chmod modifications were timing out, even though
the upload itself was successful.
Multipart upload is ready for use. A couple of
error checks are still needed in the function and
some cleanup. Need some feedback on how it
is working though.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@298 df820570-a93a-0410-bd06-b72b767a4274
Check issue #142 for details
Code is operational, but not quite ready for
prime time -- needs some clean up
git-svn-id: http://s3fs.googlecode.com/svn/trunk@297 df820570-a93a-0410-bd06-b72b767a4274
refactoring easier and the code easier to understand (for me anyway)
Opened up the VERIFY macro so that memory cleanup can be done
before returning from a function.
Make the file descriptor function calls a bit more robust,
check the return codes.
Current code tested on Debian sid, CentOS (with FUSE 2.84) and Ubuntu 10.10
git-svn-id: http://s3fs.googlecode.com/svn/trunk@286 df820570-a93a-0410-bd06-b72b767a4274
No tarball until further testing on other platforms.
Extensively tested on Debian sid 64bit
Resolves issue #104
git-svn-id: http://s3fs.googlecode.com/svn/trunk@285 df820570-a93a-0410-bd06-b72b767a4274
expose the curl compiled with openssl vs. nss issue.
If the issue is seen, emit an informational message
and give the user an option to over-ride checking of
the hostname -- it's recommended not to use bucket
names with periods and https
As implied, added an option ssl_verify_hostname=[0|1]
Tested on fedora 14. Will check on Ubuntu/Debian/CentOS
after check in.
Resolves issue #128
git-svn-id: http://s3fs.googlecode.com/svn/trunk@270 df820570-a93a-0410-bd06-b72b767a4274
trapping the CURLE_SSL_CACERT error and trying to automatically
correct it.
Tested on CentOS 5.5 and ensured that Debian/Ubuntu doesn't break
because of this. This only applies to the https usage.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@269 df820570-a93a-0410-bd06-b72b767a4274
directory from the trunk directory.
First do a svn cp of all of the source up to
trunk. This is supposed to preserve change
history -- we'll see.
The source remains untouched until this gets
worked out.
Also in preparation of bringing in the source
collateral for the debian package into the
repository. I expect that the top level will
look like this:
svn/
s3fs/
trunk/
tags/
branches/
dpkg/
trunk/
tags/
branches/
So far that's how it is looking. I'll be
very careful to ensure integrity of the data.
As a result this may be a multistep process.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@236 df820570-a93a-0410-bd06-b72b767a4274
