Re: [Fab-user] Proposed changes to contrib.files

[Bruno Clermont]

Thanks a lot!

Yes, In fact my patch was a quick rewrite to release previously working code.

I'm working to fix those bugs and merge with git master.

In fact, I saw that someone already fixed that Windows temporary file bug somewhere else in contrib.files, so I'm going to pick the same fix in put_from_text()

On Wed, Nov 18, 2009 at 13:24, Kevin Horn <address@hidden> wrote:

On Wed, Nov 18, 2009 at 12:22 PM, Kevin Horn <address@hidden> wrote:

On Thu, Nov 12, 2009 at 9:00 AM, Bruno Clermont <address@hidden> wrote:

Hi Jeff,

I just added an other patch for this issue.

It's an other function I created to solve some of my needs. It's like put() but with directory support.

It don't use rsync. It use instead the Python tarfile module... so it can work on windows without rsync (but I never tried it).

It create a temporary archive from a directory, send it, remotely extract it and change ownership.

Bruno,

I tried out your put_dir function, and while I really like the idea, it still needs some work.  Here are a few issues I found (and how I worked around them):

1. "datadir" is undefined, should be "dst"?
(fixed this with "datadir = dst")

2. os.dirsep does not exist on my system (py2.6), did you mean os.sep?
(I had to remove it anyway, see #3 below)

3. when putting a file from windows to unix, the path separator gets messed up:

    [hostname] run: tar -xvfj ~/tmp/\28d32c25-4438-46ed-a013-7e8a607aa99f.tar.bz2

notice the "/\".  I'm not sure what the best solution for this is.  Maybe fabric needs to define a variable for the path separator on the remote system?
(I just took out the separator and made sure the right separator was in my "remote_tmp" variable)

4. tar -xvfj is not valid, "f" must be the last parameter
(modified the format string to put the format before the "f")

I've modified your code to work for my specific use case, but I don't think it would work anywhere else at the moment.  I'd really like to see this cleaned up and put in fabric.contrib.  It's very handy on systems that don't have typical Unix utils like tar, gzip, bzip, etc.

Thanks for coming up with this idea!

Kevin Horn

I forgot to mention one other thing:

5. the call to os.unlink() fails on Win32, because there is still a handle open to the file, and Windows is very picky about simultaneous access to files. I just remomved the call, but it might be possible to just move the call to a later point in the program, after the handle has been released.

Kevin Horn

_______________________________________________
Fab-user mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/fab-user