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
all work from the copy of source files up on directory
...and the history is still there.
Not deleting the directories yet because need to
preserve svn properties -- not sure how to copy
vs. recreate -- need to look it up
On the todo list: remove s3fs, s3fs/src and s3fs/test
git-svn-id: http://s3fs.googlecode.com/svn/trunk@237 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
Sending DEBUG messages to syslog is off by default.
-d (or --debug) enables DEBUG messages to go to
syslog
Additionally, if an additional -d command line option
is given, then the -d option is passed to FUSE, upon
which FUSE outputs debug messages to STDOUT
resolves issue #120
git-svn-id: http://s3fs.googlecode.com/svn/trunk@235 df820570-a93a-0410-bd06-b72b767a4274
- The script was looking for /root/.passwd-s3fs on my debian
machine (it worked correctly on Ubuntu). Fixed the common.sh
file to always look in the SUDO_USER's home directory
- Added the passwd_file option to the s3fs command. Since the
test runs as root, the $SUDO_USER's password file wasn't
being looked for by the program itself. Instead the normal
precedence was being followed and the /etc/passwd-s3fs file
was being used.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@234 df820570-a93a-0410-bd06-b72b767a4274
If any password file is used, regardless if it is specified
on the command line, ~/.passwd-s3fs or /etc/passwd-s3fs it
is checked for appropriate permissions.
No password file is allowed to have any others permissions
Only the /etc/passwd-s3fs file is allowed to have any
group permissions, all others are not allowed to have
any group permissions.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@233 df820570-a93a-0410-bd06-b72b767a4274
The correct way to solve this is to consistently faily when mounting. Also offer a flag to forcefully create the bucket if it doesn't yet exist.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@231 df820570-a93a-0410-bd06-b72b767a4274
To run integration tests, just use: sudo make check
This will give you a report of all passes and failures.
To add an integration test, just add it to the TESTS variable in s3fs/test/Makefile.am
Make sure your test sources integration-test-common.sh and require-root.sh
Having many of these for every feature will help us avoid regressions and develop with confidence.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@230 df820570-a93a-0410-bd06-b72b767a4274
Add support for mulitple access id/secret access keys in passwd-s3fs file
This change applies to any passwd-s3fs files.
The format of the file is more robust, error checked and extended:
- as before, any line beginning with # is ignored
- any empty line is ignored
- any non-ignored line which contains a space or tab is an error
- any non-ignored line which does not contain a : separator is an error
The format of the file is:
[bucket:]AccessKeyId:SecretAccessKey
The bucket can now be specified to allow for multiple credentials.
A default entry is as before:
AccessKeyId:SecretAccessKey
Only one default entry is allowed, if more than one default entry
is found, that is an error. A default entry is not required, if the
bucket that is being mounted has its own entry.
If the user's .passwd-s3fs file is present but credentials cannot
be determined from it, then the system-wide /etc/passwd-s3fs will
be consulted (if readable by the current user).
This change is completely backward compatable with the existing
scheme and has been well tested.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@229 df820570-a93a-0410-bd06-b72b767a4274
Issue #102 --help command line
Issue #107 command line checking and other error checking
Issue #112 uses getopt_long now, but FUSE's own parser is still there
some command line checking is split between main() and the
helper function
Issue #117 command line option for credentials file
Issue #118 use of environment variables for credentials
Issue #119 support for a local passwd-s3fs file
Big checkin, many new lines of code.
Comand line option checking is now more robust and does quite
a bit of error checking before handing the mount off to FUSE.
Cleaned up the code and made several new functions from
existing code
Many ways to supply credentials now and there is a precedance
order followed.
--help is helpful
git-svn-id: http://s3fs.googlecode.com/svn/trunk@227 df820570-a93a-0410-bd06-b72b767a4274
If the "public_bucket=1" option is used, then
the command line options for Access Key ID and
Secret Access Key are ignored as well as the
/etc/passwd-s3fs file
Internally, the "Authorization: AWS ..." header
line is not included in the header.
Tested on a public bucket and it appears to work.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@221 df820570-a93a-0410-bd06-b72b767a4274
=========================
Removed extra space in the message emitted by --version
M s3fs/src/Makefile.am
==========================
Added the .h files to the s3fs_SOURCES. These files
were not being included in the .tar.gz file when
"make dist" was being executed. This was sourced
as an error with the "make distcheck" target.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@217 df820570-a93a-0410-bd06-b72b767a4274
Used the compile time VERSION define
Version message conforms to GNU Coding Standards
git-svn-id: http://s3fs.googlecode.com/svn/trunk@213 df820570-a93a-0410-bd06-b72b767a4274
readme.txt has been moved to README
removal of Eclipse CDT project files
git-svn-id: http://s3fs.googlecode.com/svn/trunk@212 df820570-a93a-0410-bd06-b72b767a4274
This is probably wasted work though since issue #99
is going to get the build process on autotools.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@207 df820570-a93a-0410-bd06-b72b767a4274
Tricky way to generate the distribution tar.gz file
before the autotools way is implemented
git-svn-id: http://s3fs.googlecode.com/svn/trunk@204 df820570-a93a-0410-bd06-b72b767a4274
upper case letters.
Research shows that many S3 tools do not support buckets whose
names contain uppercase characters -- s3fs appears to be no
different. However, s3fs allows a bucket of this type to be
mounted even though access to it results in a "Input/output error"
Rather than put support in for these buckets, it's easier to
inform the user of the offending bucket name and die.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@203 df820570-a93a-0410-bd06-b72b767a4274
chregu's code stream
Tested the use_rrs=1 option and confirmed that the files in the
bucket are being tagged as using RRS through Amazon's AWS cockpit
git-svn-id: http://s3fs.googlecode.com/svn/trunk@200 df820570-a93a-0410-bd06-b72b767a4274
of compiling unconditionally at every invocation of
make - actually look at the dependancy
git-svn-id: http://s3fs.googlecode.com/svn/trunk@199 df820570-a93a-0410-bd06-b72b767a4274
Applied supplied patch.
The patch solves this issue by modifying the lookupMimeType function to not only
analyze the last extension for a matching mime type, but analyze the second
to last extension if the last extension did not result in a match.
git-svn-id: http://s3fs.googlecode.com/svn/trunk@198 df820570-a93a-0410-bd06-b72b767a4274
