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
