davea at ieee.org
Mon Feb 14 00:56:59 CET 2011
On 01/-10/-28163 02:59 PM, ecu_jon wrote:
> first let me say, you guys are helping me and i thank you for that. i
> do not want to sound confrontational. i have don my best to make this
> os agnostic. yes i know, right now in 21a, destination2 is windows
> specific. that's mostly because os.path.isdir() and unc paths do not
> play well with each other.
> the os.chdir() came about out of need to build relative path names.
> some examples :
> c:\users\name\backup\ #win7
> c:\docs and settings\name\app data\backup\ #winxp
> /home/name/backup #linux and mac
In what way do those imply a need for chdir() ? What's wrong with
> i wanted to start from 'backup' in all these cases. my destination is
> going to look like
> yes os.walk goes thru the whole tree (under backup in my case). the
> os.chdir() under the for line in def backupall(): basically juct
> chages folders to whever the os.walk() is. it never tried to change to
> a different drive letter.
And I quote from facbac-012a.py:
> the folder copy thing, these 2 lines
> if os.path.isdir(fname): #if it is a folder
> if not os.path.isdir(destination+leftover): #and id
> dont exist on dest drive
> work on version 011, determine if its a folder, then if it exists.
> only copy if both: it is a folder, and not exist on destination.
> this "return homedir" needed to be moved 1 tab left. copy error from
> random code to functionalizing parts. good catch thanks.
> dirlsit, returns the names of folders and files. i was using a
> different method
> try version 11 for yourself. in your home directory (ie: /home/name)
> make a backup folder, put a few files/folders in it. then make a
> backup2 folder, and make week1,week2week3week4 folders. version 11
> will copy the top level files under /home/name/backup , and recreate
> the directory structure. so "You're not copying the files at the top
> level at all; you don't process
> the list called 'files', while you could probably safely copy *only*
> files. " atleats for version 11 is not true. atleast not within the
> bounds i have tested it.
> "Your name manipulations in this same function look risky, using
> when you presumably know that a string is either at the begin or end.
> i know. i have several things that need to build up. like starting
> from a relative position and going to a different position. username
> would be part of the unc path if i could get that to work, and
> week[1-4] is part of the name.
> the thing that gets me is version 11 works. well. but its is reading/
> writing to almost the same place (from backup, to backup2). defiantly
> open to suggestions.
I didn't spot the dirlist before, since it's totally unnecessary. It
just builds the same list you already have as 'files'. I thought you
were looping over the names in dirs. copytree() is also redundant, as
it'll cause the same files to be repeatedly copied. If you plan to use
copytree, why bother using os.walk at all?
I suggest you actually try writing a simple loop using os.walk to just
display the names of all the files in and under a specified directory.
Then maybe you'll understand what path, dirs, and files actually are.
Once you have that, use string manipulation to change the source path
name into a destination path, and print, rather than actually doing the
More information about the Python-list