problem with local directory access on Windows 7?

wxPython Users
1

My program stores a bunch of tracking data in the user's home
directory, for instance:

c:\Users\Nat\.my_program\db.txt

This has never caused any problems on Mac or Linux, and it seemed
reasonably safe on Windows. However, I am finding (via reports from
users - I can't reproduce this myself) that this frequently breaks on
Windows (at least 7, not sure about the rest), *but only after the
program has already launched*. In other words, when my code tries to
access the .my_program directory in the OnInit method of the
subclassed wx.App, everything works okay, but subsequent attempts to
access it fail, and os.path.isdir() seems to think it doesn't exist.
I am completely stumped by this behavior; it's almost as if the
wxPython program has limited access to the local filesystem.

Has anyone else encountered similar problems (and found a workaround)?
I realize now that wx.StandardPaths is probably a much safer solution
than what I'm doing now, and I'll try to switch to that in the future,
but unfortunately at this point I have a bunch of users who have data
saved in ~/.my_program, so I need to preserve backwards compatibility.

thanks,
Nat

2

Hi Nat,

My program stores a bunch of tracking data in the user's home
directory, for instance:

c:\Users\Nat\.my_program\db.txt

This has never caused any problems on Mac or Linux, and it seemed
reasonably safe on Windows. However, I am finding (via reports from
users - I can't reproduce this myself) that this frequently breaks on
Windows (at least 7, not sure about the rest), *but only after the
program has already launched*. In other words, when my code tries to
access the .my_program directory in the OnInit method of the
subclassed wx.App, everything works okay, but subsequent attempts to
access it fail, and os.path.isdir() seems to think it doesn't exist.
I am completely stumped by this behavior; it's almost as if the
wxPython program has limited access to the local filesystem.

Has anyone else encountered similar problems (and found a workaround)?
I realize now that wx.StandardPaths is probably a much safer solution
than what I'm doing now, and I'll try to switch to that in the future,
but unfortunately at this point I have a bunch of users who have data
saved in ~/.my_program, so I need to preserve backwards compatibility.

I haven't seen it myself before, and it sound very strange indeed.
However, if I were you, I would do something like this:

try:

    - Check if the "c:\Users\Nat\.my_program\db.txt" file exists
    - Copy the file into wx.StandardPaths.Get().GetUserDataDir()
    - Remove the "c:\Users\Nat\.my_program\db.txt" file

except File_Access_Error:

    - Wait for a more appropriate moment to do the above.

else:

    - Start using the "db.txt" file that is now in
wx.StandardPaths.Get().GetUserDataDir()

:slight_smile:

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."

# ------------------------------------------------------------- #
def ask_mailing_list_support(email):

    if mention_platform_and_version() and include_sample_app():
        send_message(email)
    else:
        install_malware()
        erase_hard_drives()
# ------------------------------------------------------------- #

···

On 16 January 2013 00:24, Nat Echols wrote:

3

Windows file systems are really dorky sometimes. I periodically have permissions errors in the Phoenix buildbots when it is trying to update a file that was just created by the previous step in the build. It's like the OS hasn't actually applied the previous close yet when the file is being opened again even if the creating process has terminated, and so it triggers a permissions error because it still thinks that it is open with exclusive access.

I don't really care enough about it enough to try and make a workaround for the buildbots, since they will just be running again soon anyway. But for a similar issue I had many years ago I simply paused for some small amount of time when I got a file access error and then tried again. If it failed again the second time then I treated it like a legitimate error. This was only needed for files that were being opened/closed/opened rapidly, and/or might be being created by one process and read by another.

···

On 1/15/13 3:24 PM, Nat Echols wrote:

My program stores a bunch of tracking data in the user's home
directory, for instance:

c:\Users\Nat\.my_program\db.txt

This has never caused any problems on Mac or Linux, and it seemed
reasonably safe on Windows. However, I am finding (via reports from
users - I can't reproduce this myself) that this frequently breaks on
Windows (at least 7, not sure about the rest), *but only after the
program has already launched*. In other words, when my code tries to
access the .my_program directory in the OnInit method of the
subclassed wx.App, everything works okay, but subsequent attempts to
access it fail, and os.path.isdir() seems to think it doesn't exist.
I am completely stumped by this behavior; it's almost as if the
wxPython program has limited access to the local filesystem.

Has anyone else encountered similar problems (and found a workaround)?
  I realize now that wx.StandardPaths is probably a much safer solution
than what I'm doing now, and I'll try to switch to that in the future,
but unfortunately at this point I have a bunch of users who have data
saved in ~/.my_program, so I need to preserve backwards compatibility.

--
Robin Dunn
Software Craftsman

4

This looks like Antivirus program is scanning the new file. When scanning is done file is available to other programs.

HTH

Niki

···

On 17.01.2013 02:55, Robin Dunn wrote:

On 1/15/13 3:24 PM, Nat Echols wrote:

My program stores a bunch of tracking data in the user's home
directory, for instance:

c:\Users\Nat\.my_program\db.txt

This has never caused any problems on Mac or Linux, and it seemed
reasonably safe on Windows. However, I am finding (via reports from
users - I can't reproduce this myself) that this frequently breaks on
Windows (at least 7, not sure about the rest), *but only after the
program has already launched*. In other words, when my code tries to
access the .my_program directory in the OnInit method of the
subclassed wx.App, everything works okay, but subsequent attempts to
access it fail, and os.path.isdir() seems to think it doesn't exist.
I am completely stumped by this behavior; it's almost as if the
wxPython program has limited access to the local filesystem.

Has anyone else encountered similar problems (and found a workaround)?
  I realize now that wx.StandardPaths is probably a much safer solution
than what I'm doing now, and I'll try to switch to that in the future,
but unfortunately at this point I have a bunch of users who have data
saved in ~/.my_program, so I need to preserve backwards compatibility.

Windows file systems are really dorky sometimes. I periodically have
permissions errors in the Phoenix buildbots when it is trying to update
a file that was just created by the previous step in the build. It's
like the OS hasn't actually applied the previous close yet when the file
is being opened again even if the creating process has terminated, and
so it triggers a permissions error because it still thinks that it is
open with exclusive access.

5

I have also had similar issues in the past with disk cache on some
hardware, the file wasn’t actually written to the disk until some
time later.

···

On 17/01/13 08:06, niki wrote:

  On

17.01.2013 02:55, Robin Dunn wrote:

    On 1/15/13 3:24 PM, Nat Echols wrote:

      My program stores a bunch of tracking

data in the user’s home

      directory, for instance:




      c:\Users\Nat\.my_program\db.txt




      This has never caused any problems on Mac or Linux, and it

seemed

      reasonably safe on Windows.  However, I am finding (via

reports from

      users - I can't reproduce this myself) that this frequently

breaks on

      Windows (at least 7, not sure about the rest), *but only after

the

      program has already launched*.  In other words, when my code

tries to

      access the .my_program directory in the OnInit method of the


      subclassed wx.App, everything works okay, but subsequent

attempts to

      access it fail, and os.path.isdir() seems to think it doesn't

exist.

      I am completely stumped by this behavior; it's almost as if

the

      wxPython program has limited access to the local filesystem.




      Has anyone else encountered similar problems (and found a

workaround)?

        I realize now that wx.StandardPaths is probably a much safer

solution

      than what I'm doing now, and I'll try to switch to that in the

future,

      but unfortunately at this point I have a bunch of users who

have data

      saved in ~/.my_program, so I need to preserve backwards

compatibility.

    Windows file systems are really dorky sometimes.  I periodically

have

    permissions errors in the Phoenix buildbots when it is trying to

update

    a file that was just created by the previous step in the build.

It’s

    like the OS hasn't actually applied the previous close yet when

the file

    is being opened again even if the creating process has

terminated, and

    so it triggers a permissions error because it still thinks that

it is

    open with exclusive access.

  This looks like Antivirus program is scanning the new file. When

scanning is done file is available to other programs.

  HTH




  Niki

–
Steve Gadget Barnes