Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #43394 > unrolled thread

shutil.copyfile is incomplete (truncated)

Back to article view | Back to comp.lang.python

Contents

  shutil.copyfile is incomplete (truncated) Rob Schneider <rmschne@gmail.com> - 2013-04-11 11:12 -0700
    Re: shutil.copyfile is incomplete (truncated) Neil Cerutti <neilc@norwich.edu> - 2013-04-11 18:53 +0000
      Re: shutil.copyfile is incomplete (truncated) Rob Schneider <rmschne@gmail.com> - 2013-04-11 12:07 -0700
        Re: shutil.copyfile is incomplete (truncated) Neil Cerutti <neilc@norwich.edu> - 2013-04-11 19:55 +0000
          Re: shutil.copyfile is incomplete (truncated) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-12 00:06 +0000
            Re: shutil.copyfile is incomplete (truncated) Cameron Simpson <cs@zip.com.au> - 2013-04-12 11:15 +1000
            Re: shutil.copyfile is incomplete (truncated) Ned Deily <nad@acm.org> - 2013-04-11 18:33 -0700
              Re: shutil.copyfile is incomplete (truncated) Rob Schneider <rmschne@gmail.com> - 2013-04-11 23:32 -0700
                Re: shutil.copyfile is incomplete (truncated) Rob Schneider <rmschne@gmail.com> - 2013-04-11 23:53 -0700
                  Re: shutil.copyfile is incomplete (truncated) Ned Deily <nad@acm.org> - 2013-04-12 00:53 -0700
                Re: shutil.copyfile is incomplete (truncated) Rob Schneider <rmschne@gmail.com> - 2013-04-11 23:53 -0700
                Re: shutil.copyfile is incomplete (truncated) Cameron Simpson <cs@zip.com.au> - 2013-04-12 18:26 +1000
                  Re: shutil.copyfile is incomplete (truncated) Rob Schneider <rmschne@gmail.com> - 2013-04-12 02:18 -0700
                    Re: shutil.copyfile is incomplete (truncated) Chris Angelico <rosuav@gmail.com> - 2013-04-12 19:22 +1000
                      Re: shutil.copyfile is incomplete (truncated) Rob Schneider <rmschne@gmail.com> - 2013-04-12 05:07 -0700
                        Re: shutil.copyfile is incomplete (truncated) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-12 13:18 +0100
                      Re: shutil.copyfile is incomplete (truncated) Rob Schneider <rmschne@gmail.com> - 2013-04-12 05:07 -0700
                  Re: shutil.copyfile is incomplete (truncated) Rob Schneider <rmschne@gmail.com> - 2013-04-12 02:18 -0700
                    Re: shutil.copyfile is incomplete (truncated) Roy Smith <roy@panix.com> - 2013-04-12 10:57 -0400
                  Re: shutil.copyfile is incomplete (truncated) Roy Smith <roy@panix.com> - 2013-04-12 10:54 -0400
              Re: shutil.copyfile is incomplete (truncated) Rob Schneider <rmschne@gmail.com> - 2013-04-11 23:32 -0700
                Re: shutil.copyfile is incomplete (truncated) Roy Smith <roy@panix.com> - 2013-04-12 10:47 -0400
            Re: shutil.copyfile is incomplete (truncated) Rob Schneider <rmschne@gmail.com> - 2013-04-11 23:27 -0700
            Re: shutil.copyfile is incomplete (truncated) Roy Smith <roy@panix.com> - 2013-04-12 10:51 -0400
            Re: shutil.copyfile is incomplete (truncated) 88888 Dihedral <dihedral88888@googlemail.com> - 2013-04-12 08:49 -0700
            Re: shutil.copyfile is incomplete (truncated) Nobody <nobody@nowhere.com> - 2013-04-13 03:33 +0100
              Re: shutil.copyfile is incomplete (truncated) Chris Angelico <rosuav@gmail.com> - 2013-04-13 13:05 +1000
              [OT] Lying hard drives [was Re: shutil.copyfile is incomplete (truncated)] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-13 03:17 +0000
                Re: [OT] Lying hard drives [was Re: shutil.copyfile is incomplete (truncated)] Chris Angelico <rosuav@gmail.com> - 2013-04-13 13:43 +1000
          Re: shutil.copyfile is incomplete (truncated) Rob Schneider <rmschne@gmail.com> - 2013-04-11 23:25 -0700
            Re: shutil.copyfile is incomplete (truncated) Chris Angelico <rosuav@gmail.com> - 2013-04-12 17:32 +1000
            Re: shutil.copyfile is incomplete (truncated) Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-12 10:48 -0400

Page 1 of 2  [1] 2  Next page →

#43394 — shutil.copyfile is incomplete (truncated)

Using Python 2.7.2 on OSX, I have created a file in temp space, then use the function "shutil.copyfile(fn,loc+fname)" from "fn" to "loc+fname".

At the destination location, the file is truncated. About 10% of the file is lost.  Original file is unchanged.

I added calls to "statinfo" immediately after the copy, and all looks ok (correct file size).

filecmp.cmp(fn,loc+fname)
print "Statinfo    :"+fn+":\n", os.stat(fn)
print "Statinfo    :"+loc+fname+":\n", os.stat(loc+fname)

But when I look at the file in Finder, destination is smaller and even looking at the file (with text editor) file is truncated.

What could be causing this?

[toc] | [next] | [standalone]

#43398

On 2013-04-11, Rob Schneider <rmschne@gmail.com> wrote:
> Using Python 2.7.2 on OSX, I have created a file in temp space,
> then use the function "shutil.copyfile(fn,loc+fname)" from "fn"
> to "loc+fname".
>
> At the destination location, the file is truncated. About 10%
> of the file is lost.  Original file is unchanged.
>
> I added calls to "statinfo" immediately after the copy, and all
> looks ok (correct file size).
>
> filecmp.cmp(fn,loc+fname)
> print "Statinfo    :"+fn+":\n", os.stat(fn)
> print "Statinfo    :"+loc+fname+":\n", os.stat(loc+fname)
>
> But when I look at the file in Finder, destination is smaller
> and even looking at the file (with text editor) file is
> truncated.
>
> What could be causing this?

Could fn be getting some changes written after the copy is made?

Is the file flushed/closed before you copy it?

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#43400

Thanks. Yes, there is a close function call  before the copy is launched. No other writes.
Does Python wait for file close command to complete before proceeding?

[toc] | [prev] | [next] | [standalone]

#43402

On 2013-04-11, Rob Schneider <rmschne@gmail.com> wrote:
> Thanks. Yes, there is a close function call  before the copy is
> launched. No other writes. Does Python wait for file close
> command to complete before proceeding?

The close method is defined and flushing and closing a file, so
it should not return until that's done.

What command are you using to create the temp file?

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#43405

On Thu, 11 Apr 2013 19:55:53 +0000, Neil Cerutti wrote:

> On 2013-04-11, Rob Schneider <rmschne@gmail.com> wrote:
>> Thanks. Yes, there is a close function call  before the copy is
>> launched. No other writes. Does Python wait for file close command to
>> complete before proceeding?
> 
> The close method is defined and flushing and closing a file, so it
> should not return until that's done.

But note that "done" in this case means "the file system thinks it is 
done", not *actually* done. Hard drives, especially the cheaper ones, 
lie. They can say the file is written when in fact the data is still in 
the hard drive's internal cache and not written to the disk platter. 
Also, in my experience, hardware RAID controllers will eat your data, and 
then your brains when you try to diagnose the problem.

I would consider the chance that the disk may be faulty, or the file 
system is corrupt. Does the problem go away if you write to a different 
file system or a different disk?



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#43411

On 12Apr2013 00:06, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
| On Thu, 11 Apr 2013 19:55:53 +0000, Neil Cerutti wrote:
| > On 2013-04-11, Rob Schneider <rmschne@gmail.com> wrote:
| >> Thanks. Yes, there is a close function call  before the copy is
| >> launched. No other writes. Does Python wait for file close command to
| >> complete before proceeding?
| > 
| > The close method is defined and flushing and closing a file, so it
| > should not return until that's done.
| 
| But note that "done" in this case means "the file system thinks it is 
| done", not *actually* done.

Unless there's a reboot (or crash) in between, the view from the
app should be consistent and correct.

| Hard drives, especially the cheaper ones, 
| lie. They can say the file is written when in fact the data is still in 
| the hard drive's internal cache and not written to the disk platter. 
| Also, in my experience, hardware RAID controllers will eat your data, and 
| then your brains when you try to diagnose the problem.
| 
| I would consider the chance that the disk may be faulty, or the file 
| system is corrupt. Does the problem go away if you write to a different 
| file system or a different disk?

Or that the filesystem may be full? Of course, that's usually obvious
more widely when it happens...

Question: is the size of the incomplete file a round number? (Like
a multiple of a decent sized power of 2>)

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

I am now convinced that theoretical physics is actual philosophy.
        - Max Born

[toc] | [prev] | [next] | [standalone]

#43412

In article <20130412011550.GA80724@cskk.homeip.net>,
 Cameron Simpson <cs@zip.com.au> wrote:
> Or that the filesystem may be full? Of course, that's usually obvious
> more widely when it happens...
> 
> Question: is the size of the incomplete file a round number? (Like
> a multiple of a decent sized power of 2>)

Also on what OS X file system type does the file being created reside, 
in particular, is it a network file system?

-- 
 Ned Deily,
 nad@acm.org

[toc] | [prev] | [next] | [standalone]

#43424

> 
> > Or that the filesystem may be full? Of course, that's usually obvious
> 
> > more widely when it happens...
> 
> > 
> 
> > Question: is the size of the incomplete file a round number? (Like
> 
> > a multiple of a decent sized power of 2>)
> 
> 
> 
> Also on what OS X file system type does the file being created reside, 
> 
> in particular, is it a network file system?
> 

File system not full (2/3 of disk is free)

Source (correct one) is 47,970 bytes. Target after copy of 45,056 bytes.  I've tried changing what gets written to change the file size. It is usually this sort of difference.

The file system is Mac OS Extended Journaled (default as out of the box).  

[toc] | [prev] | [next] | [standalone]

#43425

> The file system is Mac OS Extended Journaled (default as out of the box).

I ran a repair disk .. .while it found and fixed what it called "minor" problems, it did something.  However, the repair did not fix the problem. I just ran the program again and the source is 47,970 bytes and target after copy if 45,056.

Interestingly, the test I run just after the copy , i run a file compare:

code:

 if showproperties: 
                    print "Filecompare :",filecmp.cmp(fn,loc+fname)
                    print "Statinfo    :"+fn+":\n", os.stat(fn)
                    print "Statinfo    :"+loc+fname+":\n", os.stat(loc+fname)

results:

Filecompare : True
Statinfo    :/var/folders/p_/n5lktj2n0r938_46jyqb52g40000gn/T/speakers.htm:
posix.stat_result(st_mode=33188, st_ino=32205850, st_dev=16777218L, st_nlink=1, st_uid=501, st_gid=20, st_size=45056, st_atime=1365749178, st_mtime=1365749178, st_ctime=1365749178)
Statinfo    :/Users/rmschne/Documents/ScottishOilClub/SOC Board Doc Sharing Folder/Meetings/speakers.htm:
posix.stat_result(st_mode=33188, st_ino=32144179, st_dev=16777218L, st_nlink=1, st_uid=501, st_gid=20, st_size=45056, st_atime=1365749178, st_mtime=1365749178, st_ctime=1365749178)

It shows file size 45,056 on both source and target, which is the file size of the flawed target, and is not what Finder shows for source.

Sigh.

[toc] | [prev] | [next] | [standalone]

#43431

In article <6eeabeb2-e6dd-49fc-bd64-8de53965189b@googlegroups.com>,
 Rob Schneider <rmschne@gmail.com> wrote:
> > The file system is Mac OS Extended Journaled (default as out of the box).
> It shows file size 45,056 on both source and target, which is the file size 
> of the flawed target, and is not what Finder shows for source.

Perhaps the source file has an OS X resource fork or other extended 
attribute metadata.  shutil's copy functions won't handle those.  One 
way to see if that is the case is to examine the source file in a 
terminal window with:  ls -l@

$ ls -l@ test.jpg
-rw-r--r--@ 1 nad  staff  40359 Jul 15  2009 test.jpg
   com.apple.FinderInfo    32
   com.apple.ResourceFork  899489

-- 
 Ned Deily,
 nad@acm.org

[toc] | [prev] | [next] | [standalone]

#43426

> The file system is Mac OS Extended Journaled (default as out of the box).

I ran a repair disk .. .while it found and fixed what it called "minor" problems, it did something.  However, the repair did not fix the problem. I just ran the program again and the source is 47,970 bytes and target after copy if 45,056.

Interestingly, the test I run just after the copy , i run a file compare:

code:

 if showproperties: 
                    print "Filecompare :",filecmp.cmp(fn,loc+fname)
                    print "Statinfo    :"+fn+":\n", os.stat(fn)
                    print "Statinfo    :"+loc+fname+":\n", os.stat(loc+fname)

results:

Filecompare : True
Statinfo    :/var/folders/p_/n5lktj2n0r938_46jyqb52g40000gn/T/speakers.htm:
posix.stat_result(st_mode=33188, st_ino=32205850, st_dev=16777218L, st_nlink=1, st_uid=501, st_gid=20, st_size=45056, st_atime=1365749178, st_mtime=1365749178, st_ctime=1365749178)
Statinfo    :/Users/rmschne/Documents/ScottishOilClub/SOC Board Doc Sharing Folder/Meetings/speakers.htm:
posix.stat_result(st_mode=33188, st_ino=32144179, st_dev=16777218L, st_nlink=1, st_uid=501, st_gid=20, st_size=45056, st_atime=1365749178, st_mtime=1365749178, st_ctime=1365749178)

It shows file size 45,056 on both source and target, which is the file size of the flawed target, and is not what Finder shows for source.

Sigh.

[toc] | [prev] | [next] | [standalone]

#43433

On 11Apr2013 23:32, Rob Schneider <rmschne@gmail.com> wrote:
| > > Question: is the size of the incomplete file a round number? (Like
| > > a multiple of a decent sized power of 2>)
[...]
| Source (correct one) is 47,970 bytes. Target after copy of 45,056
| bytes.  I've tried changing what gets written to change the file
| size. It is usually this sort of difference.

45046 is exactly 11 * 4096. I'd say your I/O is using 4KB blocks,
and the last partial block (to make it up to 47970) didn't get
written (at the OS level).

Earlier you wrote:
| I have created a file in temp space, then use the function
| "shutil.copyfile(fn,loc+fname)" from "fn" to "loc+fname".
and:
| Yes, there is a close function call  before the copy is launched. No other writes.
| Does Python wait for file close command to complete before proceeding?

Please show us the exact code used to make the temp file.

I would guess the temp file has not been closed (or flushed) before
the call to copyfile.

If you're copying data to a tempfile, it will only have complete
buffers (i.e. multiples of 4096 bytes) in it until the final flush
or close.

So I'm imagining something like:

  tfp = open(tempfilename, "w")
  ... lots of tfp.write() ...
  shutil.copyfile(tempfilename, newfilename)

Note above no flush or close of tfp. So the final incomplete I/O
buffer is still in Python's memory; it hasn't been actually written
to the temp file because the buffer has not been filled, and the file
has not been closed.

Anyway, can you show us the relevant bits of code involved?

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

Processes are like potatoes.    - NCR device driver manual

[toc] | [prev] | [next] | [standalone]

#43434

On Friday, 12 April 2013 09:26:21 UTC+1, Cameron Simpson  wrote:
> 
> | > > Question: is the size of the incomplete file a round number? (Like
> 
> | > > a multiple of a decent sized power of 2>)
> 
> [...]
> 
> | Source (correct one) is 47,970 bytes. Target after copy of 45,056
> 
> | bytes.  I've tried changing what gets written to change the file
> 
> | size. It is usually this sort of difference.
> 
> 
> 
> 45046 is exactly 11 * 4096. I'd say your I/O is using 4KB blocks,
> 
> and the last partial block (to make it up to 47970) didn't get
> 
> written (at the OS level).
> 
> 
> 
> Earlier you wrote:
> 
> | I have created a file in temp space, then use the function
> 
> | "shutil.copyfile(fn,loc+fname)" from "fn" to "loc+fname".
> 
> and:
> 
> | Yes, there is a close function call  before the copy is launched. No other writes.
> 
> | Does Python wait for file close command to complete before proceeding?
> 
> 
> 
> Please show us the exact code used to make the temp file.
> 
> 
> 
> I would guess the temp file has not been closed (or flushed) before
> 
> the call to copyfile.
> 
> 
> 
> If you're copying data to a tempfile, it will only have complete
> 
> buffers (i.e. multiples of 4096 bytes) in it until the final flush
> 
> or close.
> 
> 
> 
> So I'm imagining something like:
> 
> 
> 
>   tfp = open(tempfilename, "w")
> 
>   ... lots of tfp.write() ...
> 
>   shutil.copyfile(tempfilename, newfilename)
> 
> 
> 
> Note above no flush or close of tfp. So the final incomplete I/O
> 
> buffer is still in Python's memory; it hasn't been actually written
> 
> to the temp file because the buffer has not been filled, and the file
> 
> has not been closed.
> 
> 
> 
> Anyway, can you show us the relevant bits of code involved?
> 
> 
> 
> Cheers,
> 
> -- 
> 
> Cameron Simpson <cs@zip.com.au>
> 
> 
> 
> Processes are like potatoes.    - NCR device driver manual

Thanks for the observation. 

Code (simplified but results in same flaw) (which a close, far as I can tell).

def CreateSpeakerList1():
    import shutil
    import filecmp
    import os.path 

    t=get_template('speaker_list.html')
    fn=TEMP_DIR+SOC_SPEAKER_LIST
    fn=tempfile.gettempdir()+"/"+SOC_SPEAKER_LIST
    f=open(fn,'w')
    speaker_list=Speaker.objects.order_by('status__order','targetmtg__date')
    print "    Creating " + SOC_SPEAKER_LIST +  " ..."
    html=(smart_str(t.render(Context(
        {
        'css_include_file':CSS_INCLUDE_FILE,
        'css_link':False,
        'title': ORG_NAME+" Speaker List",
        'speaker_list': speaker_list,
        }))))
    f.write(html)
    f.close
    print "    Wrote "+fn
    shutil.copyfile(fn,SOC_GENERAL_OUTPUT_FOLDER+SOC_SPEAKER_LIST)
    print "Filecompare :",filecmp.cmp(fn,SOC_GENERAL_OUTPUT_FOLDER+SOC_SPEAKER_LIST)
    print "Statinfo    :"+fn+":\n", os.stat(fn)
    print "Statinfo    :"+SOC_GENERAL_OUTPUT_FOLDER+SOC_SPEAKER_LIST+"\n", os.stat(SOC_GENERAL_OUTPUT_FOLDER+SOC_SPEAKER_LIST)
    return

Output on latest run:

    Creating speakers.htm ...
    Wrote /var/folders/p_/n5lktj2n0r938_46jyqb52g40000gn/T/speakers.htm
Filecompare : True
Statinfo    :/var/folders/p_/n5lktj2n0r938_46jyqb52g40000gn/T/speakers.htm:
posix.stat_result(st_mode=33188, st_ino=32332374, st_dev=16777218L, st_nlink=1, st_uid=501, st_gid=20, st_size=45056, st_atime=1365758139, st_mtime=1365758139, st_ctime=1365758139)
Statinfo    :/Users/rmschne/Documents/ScottishOilClub/Output/speakers.htm
posix.stat_result(st_mode=33188, st_ino=32143886, st_dev=16777218L, st_nlink=1, st_uid=501, st_gid=20, st_size=45056, st_atime=1365758029, st_mtime=1365758139, st_ctime=1365758139)

[toc] | [prev] | [next] | [standalone]

#43436

On Fri, Apr 12, 2013 at 7:18 PM, Rob Schneider <rmschne@gmail.com> wrote:
>   f.close

Yep, there's the problem! See my previous post for details. Change this to:

f.close()

and you should be sorted.

ChrisA

[toc] | [prev] | [next] | [standalone]

#43440

On Friday, 12 April 2013 10:22:21 UTC+1, Chris Angelico  wrote:
> On Fri, Apr 12, 2013 at 7:18 PM, Rob Schneider <rmschne@gmail.com> wrote:
> 
> >   f.close
> 
> 
> 
> Yep, there's the problem! See my previous post for details. Change this to:
> 
> 
> 
> f.close()
> 
> 
> 
> and you should be sorted.
> 
> 
> 
> ChrisA

Slapping forehead ... hard.  Thanks!

[toc] | [prev] | [next] | [standalone]

#43442

On 12/04/2013 13:07, Rob Schneider wrote:
> On Friday, 12 April 2013 10:22:21 UTC+1, Chris Angelico  wrote:
>> On Fri, Apr 12, 2013 at 7:18 PM, Rob Schneider <rmschne@gmail.com> wrote:
>>
>>>    f.close
>>
>> Yep, there's the problem! See my previous post for details. Change this to:
>>
>> f.close()
>>
>> and you should be sorted.
>>
>> ChrisA
>
> Slapping forehead ... hard.  Thanks!
>

a) We've all done it :)
b) The print function/statement or Python's interactive mode are awesome 
in situations like this.

-- 
If you're using GoogleCrap™ please read this 
http://wiki.python.org/moin/GoogleGroupsPython.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#43441

On Friday, 12 April 2013 10:22:21 UTC+1, Chris Angelico  wrote:
> On Fri, Apr 12, 2013 at 7:18 PM, Rob Schneider <rmschne@gmail.com> wrote:
> 
> >   f.close
> 
> 
> 
> Yep, there's the problem! See my previous post for details. Change this to:
> 
> 
> 
> f.close()
> 
> 
> 
> and you should be sorted.
> 
> 
> 
> ChrisA

Slapping forehead ... hard.  Thanks!

[toc] | [prev] | [next] | [standalone]

#43435

On Friday, 12 April 2013 09:26:21 UTC+1, Cameron Simpson  wrote:
> 
> | > > Question: is the size of the incomplete file a round number? (Like
> 
> | > > a multiple of a decent sized power of 2>)
> 
> [...]
> 
> | Source (correct one) is 47,970 bytes. Target after copy of 45,056
> 
> | bytes.  I've tried changing what gets written to change the file
> 
> | size. It is usually this sort of difference.
> 
> 
> 
> 45046 is exactly 11 * 4096. I'd say your I/O is using 4KB blocks,
> 
> and the last partial block (to make it up to 47970) didn't get
> 
> written (at the OS level).
> 
> 
> 
> Earlier you wrote:
> 
> | I have created a file in temp space, then use the function
> 
> | "shutil.copyfile(fn,loc+fname)" from "fn" to "loc+fname".
> 
> and:
> 
> | Yes, there is a close function call  before the copy is launched. No other writes.
> 
> | Does Python wait for file close command to complete before proceeding?
> 
> 
> 
> Please show us the exact code used to make the temp file.
> 
> 
> 
> I would guess the temp file has not been closed (or flushed) before
> 
> the call to copyfile.
> 
> 
> 
> If you're copying data to a tempfile, it will only have complete
> 
> buffers (i.e. multiples of 4096 bytes) in it until the final flush
> 
> or close.
> 
> 
> 
> So I'm imagining something like:
> 
> 
> 
>   tfp = open(tempfilename, "w")
> 
>   ... lots of tfp.write() ...
> 
>   shutil.copyfile(tempfilename, newfilename)
> 
> 
> 
> Note above no flush or close of tfp. So the final incomplete I/O
> 
> buffer is still in Python's memory; it hasn't been actually written
> 
> to the temp file because the buffer has not been filled, and the file
> 
> has not been closed.
> 
> 
> 
> Anyway, can you show us the relevant bits of code involved?
> 
> 
> 
> Cheers,
> 
> -- 
> 
> Cameron Simpson <cs@zip.com.au>
> 
> 
> 
> Processes are like potatoes.    - NCR device driver manual

Thanks for the observation. 

Code (simplified but results in same flaw) (which a close, far as I can tell).

def CreateSpeakerList1():
    import shutil
    import filecmp
    import os.path 

    t=get_template('speaker_list.html')
    fn=TEMP_DIR+SOC_SPEAKER_LIST
    fn=tempfile.gettempdir()+"/"+SOC_SPEAKER_LIST
    f=open(fn,'w')
    speaker_list=Speaker.objects.order_by('status__order','targetmtg__date')
    print "    Creating " + SOC_SPEAKER_LIST +  " ..."
    html=(smart_str(t.render(Context(
        {
        'css_include_file':CSS_INCLUDE_FILE,
        'css_link':False,
        'title': ORG_NAME+" Speaker List",
        'speaker_list': speaker_list,
        }))))
    f.write(html)
    f.close
    print "    Wrote "+fn
    shutil.copyfile(fn,SOC_GENERAL_OUTPUT_FOLDER+SOC_SPEAKER_LIST)
    print "Filecompare :",filecmp.cmp(fn,SOC_GENERAL_OUTPUT_FOLDER+SOC_SPEAKER_LIST)
    print "Statinfo    :"+fn+":\n", os.stat(fn)
    print "Statinfo    :"+SOC_GENERAL_OUTPUT_FOLDER+SOC_SPEAKER_LIST+"\n", os.stat(SOC_GENERAL_OUTPUT_FOLDER+SOC_SPEAKER_LIST)
    return

Output on latest run:

    Creating speakers.htm ...
    Wrote /var/folders/p_/n5lktj2n0r938_46jyqb52g40000gn/T/speakers.htm
Filecompare : True
Statinfo    :/var/folders/p_/n5lktj2n0r938_46jyqb52g40000gn/T/speakers.htm:
posix.stat_result(st_mode=33188, st_ino=32332374, st_dev=16777218L, st_nlink=1, st_uid=501, st_gid=20, st_size=45056, st_atime=1365758139, st_mtime=1365758139, st_ctime=1365758139)
Statinfo    :/Users/rmschne/Documents/ScottishOilClub/Output/speakers.htm
posix.stat_result(st_mode=33188, st_ino=32143886, st_dev=16777218L, st_nlink=1, st_uid=501, st_gid=20, st_size=45056, st_atime=1365758029, st_mtime=1365758139, st_ctime=1365758139)

[toc] | [prev] | [next] | [standalone]

#43460

In article <mailman.511.1365758300.3114.python-list@python.org>,
 Rob Schneider <rmschne@gmail.com> wrote:

>     f.close

Well, there's your problem.  You're not calling close.  You forgot the 
()'s after the function name!

[toc] | [prev] | [next] | [standalone]

#43459

In article <mailman.510.1365755188.3114.python-list@python.org>,
 Cameron Simpson <cs@zip.com.au> wrote:

> 45046 is exactly 11 * 4096. I'd say your I/O is using 4KB blocks,
> and the last partial block (to make it up to 47970) didn't get
> written (at the OS level).

Yeah, this sounds like a good diagnosis.

BTW, the dtruss command I recommended in my earlier post would confirm 
this.  But, to be honest, it's such a likely scenario that it hardly 
needs confirmation.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web