Front page | perl.perl5.porters |
Postings from May 2008
On Thu, 15 May 2008, David Landgren wrote:
> There are two other issues I am addressing, the fact that (stat $foo)[1]
> (the inode) always returns 0 on Windows (and thus prevents UNC paths
> from being removed), and asking to remove the current directory (or
> ancestor), for which the code now croaks when it tries to chdir back to
> the original directory at the end of the run, and it's been blown away.
>
> The solution to the first can be solved if Win32::IdentifyFile is available.
Note that all the information returned by Win32::IdentifyFile is already
available inside our win32_stat() function (unless you set
$^WIN32_SLOPPY_STAT to a true value). So we could cheaply create a fake
inode from it.
The problem is that the file id can be up to 64 bits (of which only 48
are used on NTFS I think, but it is up to the file system driver to
implement this), and st_ino is only 16 bits in the standard "struct
stat" as defined by MSVCRT.dll. A trivial way to fake an inode would be
to just xor the 64 bit file id in 16 bit chunks to fold it, but of
course you cannot avoid collisions this way. One advantage of this is
that it could be integrated into 5.10 and 5.8 if we wanted to.
Another approach might be to redefine Stat_t to our own definition and
use 64 bits for the inode inside Perl. I'm not sure if this would be
a problem for XS code, or for integration into 5.10.
Just for my information, how does the inode field prevent UNC paths from
being removed and doesn't affect other paths?
> The second is a hassle. Suppose one is in /path/to/some/dir.
>
> Given
>
> rmtree( '../../to', 'here/too', {verbose=>0} );
[...]
> So I'm thinking that the right things to do is to not croak and just
> ignore the remaining directories in the list to be unlinked, and the
> current directory remains changed.
I prefer to keep the croak. Changing the working directory as an
unintended side effect should be a fatal error:
rmtree( '../../to' );
rmtree( 'here/too' );
How do you prevent the second rmtree() from removing the wrong tree?
Cheers,
-Jan
Thread Previous
|
Thread Next