return for more specific information as to why the communication
failed. Most common reasons are the "time too skewed" or
credentials failure.
This could be extended to the curl routine that is used
during normal operation. However, the check_service routine
is a good first pass.
Resolves issue #133
git-svn-id: http://s3fs.googlecode.com/svn/trunk@275 df820570-a93a-0410-bd06-b72b767a4274
sure of the usefulness or purpose of this option, but
am including it for completeness
Re-categorized SYS_INFO messages ot SYS_DEBUG messages
to reduce the amount of spew into syslog -- these can
be turned back on with the -d option
Resolves issue #120
git-svn-id: http://s3fs.googlecode.com/svn/trunk@274 df820570-a93a-0410-bd06-b72b767a4274
defined. Added #defines around appropriate code.
Latest revision now compiles and works on CentOS
git-svn-id: http://s3fs.googlecode.com/svn/trunk@271 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
During the service_check() function, if curl returns
a CURLE_SSL_CACERT error then report it and do not
start the s3fs service.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@265 df820570-a93a-0410-bd06-b72b767a4274
rename (mv) a directory, its contents "disappear". To
get the contents back, just re-create the directory.
This issue has led to more than one support issues.
This patch disallows renaming of directories and
returns a operation not supported message, e.g.
% mv dir1 dir2
mv: cannot move `dir1' to `dir2': Operation not supported
Another observation is that when a directory was renamed
it loses its directory status and becomes a normal file.
This is a first step to allow for supporting directory
renames.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@260 df820570-a93a-0410-bd06-b72b767a4274
is not present/readable.
Don't process blank lines in mime.types
There wasn't an issue seen with this, just
cleaning up the code a bit.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@245 df820570-a93a-0410-bd06-b72b767a4274
Resolves issue #88
Specifying credentials on the command line is no longer
supported. There are several other ways to do this now.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@243 df820570-a93a-0410-bd06-b72b767a4274
with the conversion to get_opt
-f is passed along to FUSE. This makes FUSE run
in foreground (non-daemon) mode and some debugging
messages now appear on STDOUT
git-svn-id: http://s3fs.googlecode.com/svn/trunk@240 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
