in reply to Re: unlink & rename in Win32
in thread unlink & rename in Win32

Unfortunately I'm relatively sure that that isn't the case. I'm the only one with acess to the system, no other programs touch the file... and I made a point of closing it before I tried to rename it and it still complains...


-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GIT d- s:++ a--- C++++ UL P+++>++++ L+ E- W++>+++ N !o K- w+ O---- M-- V--
PS PE Y- PGP t++(+++) 5(+++)++++ X R+@ tv+ b+++ DI+ D- G e->+++ h! r-- y-
------END GEEK CODE BLOCK------
Translate

"Weird things happen, get used to it."

Flame ~ Lead Programmer: GMS

Replies are listed 'Best First'.
Re: Re: Re: unlink & rename in Win32
by IlyaM (Parson) on Dec 01, 2001 at 09:23 UTC
      I'm not exactley sure how to read this... so:
      10:57:46 AM Perl Close E:\GMS\TESTMEMBER\GMS.LOG SUCCESS + CLOSE_FINAL 10:57:49 AM Perl Open E:\GMS\TESTMEMBER\GMS.LOG SUCCESS + CREATENEW OPENEXISTING WRITEONLY DENYNONE 10:57:49 AM Perl Seek E:\GMS\TESTMEMBER\GMS.LOG SUCCESS + End Offset: 0 / New offset: 0 10:57:49 AM Perl Read E:\GMS\TESTMEMBER\GMS.LOG SUCCESS + Offset: 614400 Length: 4096 10:57:49 AM Perl Open E:\GMS\TESTMEMBER\GMS.LOG SUCCESS + OPENEXISTING READONLY DENYNONE 10:57:49 AM Perl Read E:\GMS\TESTMEMBER\GMS.LOG SUCCESS + Offset: 0 Length: 4096 10:57:49 AM Perl Read E:\GMS\TESTMEMBER\GMS.LOG SUCCESS + Offset: 1542 Length: 4096 10:57:49 AM Perl Seek E:\GMS\TESTMEMBER\GMS.LOG SUCCESS + Beginning Offset: 0 / New offset: 0 10:57:49 AM Perl Open E:\GMS\TESTMEMBER\GMS.TMP SUCCESS + CREATENEW REPLACEEXISTING WRITEONLY DENYNONE 10:57:49 AM Perl Seek E:\GMS\TESTMEMBER\GMS.TMP SUCCESS + Beginning Offset: 0 / New offset: 0 10:57:49 AM Perl Read E:\GMS\TESTMEMBER\GMS.LOG SUCCESS + Offset: 0 Length: 512 10:57:49 AM Perl Read E:\GMS\TESTMEMBER\GMS.LOG SUCCESS + Offset: 512 Length: 4096 10:57:49 AM Perl Read E:\GMS\TESTMEMBER\GMS.LOG SUCCESS + Offset: 1542 Length: 4096 10:57:49 AM Perl Write E:\GMS\TESTMEMBER\GMS.TMP SUCCESS + Offset: 0 Length: 49 10:57:49 AM Perl Close E:\GMS\TESTMEMBER\GMS.TMP SUCCESS + CLOSE_FINAL 10:57:49 AM Perl Close E:\GMS\TESTMEMBER\GMS.LOG SUCCESS + CLOSE_FINAL 10:58:10 AM Perl Attributes E:\GMS\TESTMEMBER\GMS.LOG SUCC +ESS GetAttributes 10:58:10 AM Perl Attributes E:\GMS\TESTMEMBER\GMS.LOG SUCC +ESS GetAttributes 10:58:10 AM Perl FindOpen E:\GMS\TESTMEMBER\GMS.LOG SUCCES +S GMS.log 10:58:10 AM Perl FindClose E:\GMS\TESTMEMBER\GMS.LOG SUCCE +SS 10:58:10 AM Perl Rename E:\GMS\TESTMEMBER\GMS.LOG ACCDENIE +D E:\GMS\TESTMEMBER\GMS.BAK 10:58:10 AM Perl Close E:\GMS\TESTMEMBER\GMS.LOG SUCCESS + CLOSE_FINAL



      -----BEGIN GEEK CODE BLOCK-----
      Version: 3.12
      GIT d- s:++ a--- C++++ UL P+++>++++ L+ E- W++>+++ N !o K- w+ O---- M-- V--
      PS PE Y- PGP t++(+++) 5(+++)++++ X R+@ tv+ b+++ DI+ D- G e->+++ h! r-- y-
      ------END GEEK CODE BLOCK------
      Translate

      "Weird things happen, get used to it."

      Flame ~ Lead Programmer: GMS

        Seems pretty clear to me:

        10:57:49 Perl Open E:\GMS\TESTMEMBER\GMS.LOG 10:57:49 Perl Open E:\GMS\TESTMEMBER\GMS.LOG 10:57:49 Perl Close E:\GMS\TESTMEMBER\GMS.LOG 10:58:10 Perl Rename E:\GMS\TESTMEMBER\GMS.LOG
        You open GMS.LOG twice, only close it once, then try to rename it (when you still have it open at least once).

        The default for C programs under Win32 is to allow "read" and "write" sharing but not "delete" sharing. And if a file is currently open w/o "delete" sharing having been requested, then no one (not even the process that has the file open) is allowed to delete or even rename the file.

        So you need to find which of your two file handles you are failing to close before you rename the file.

        FYI, Win32API::File has more information on Win32 file sharing and ways to open files while specifying different levels of file sharing.

        Elsewhere you asked about the "archive" bit. If the archive bit is set, that means that a file has been modified since the last time it was archived. That is, modifying the contents of a file sets the archive bit and many "backup" programs clear the archive bit when they copy the file. Also, many backup programs can be told to only backup files who have the archive bit set (which is where this whole scheme becomes useful).

                - tye (but my friends call me "Tye")
        I'm not sure if I am reading this correctly either, but have you checked to see what the permissions of E:\GMS\TESTMEMBER\GMS.BAK are? If it is read only and the rename is trying to overwrite it, it might be the source of the problem. HTH.

        --Jim

        Sorry. I can't help you with it. I've been Win32 programmer in my previous life and I hardly remember what it is about.

        --
        Ilya Martynov (http://martynov.org/)