On Apr 3, 2025, at 19:05, ToddAndMargo via perl6-users <perl6-
us...@perl.org> wrote:
> On Thu, Apr 3, 2025 at 2:14 AM ToddAndMargo via perl6-users <perl6-
> us...@perl.org <mailto:perl6-users@perl.org>> wrote:
>
> And another IO ffunctio that does ot work:
>
> RotateArchives: renaming directory
> \\192.168.240.10\oldserver\Backup\MyDocsBackup\backup6 to
> \\192.168.240.10\oldserver\Backup\MyDocsBackup\backup4
>
> Failed to rename
> 'C:\192.168.240.10\oldserver\Backup\MyDocsBackup\backup6' to
> 'C:\192.168.240.10\oldserver\Backup\MyDocsBackup\backup4': Failed to
> rename file: no such file or directory
>
> rename put a freaking C: on teh unc path.
>
> Another call to powershell. Poop!
>
>
On 4/3/25 12:08 PM, yary wrote:
The first 3 characters of the error is telling you the problem
C:\192
it's same as in another thread, use Q[\\192 ... instead of '\
\192 ... , so that you preserve the backslashes.
That other thread had that path in a variable. Raku messed
with the variable when I made the IO call. And I
can not put a variable into a Q[]. AAAAAA HHHH !!!!
OR
double each backslash- `\\\\192.168.240.10\\oldserver ... and then
you can keep using variables as you normally do.
-y
Hi Yary,
This is a glaring bug.
The call was
rename $Oldpath $NewPath
$OldPath was `\\192.168.240.10\oldserver\Backup\MyDocsBackup\backup6`
$NewPath was `\\192.168.240.10\oldserver\Backup\MyDocsBackup\backup4`
Once I have something added to a variable, it is HANDS OFF. DO
NOT MESS WITH IT. Before then, it is appreciated. BUT NOT AFTER!
Not only did rename mess with my variables, but it added `C:` to it.
If the powers-that-be ever decide to fix IO under Windows, any
workaround I do to get around the current situation will
be broken. And back to chasing ghosts again.
My solution is to add powershell calls to my NativeWinUtils.rakumod
and use them instead of raku's IO calls.
An example:
sub DirectoryExists( Str $DirPath --> Bool ) {
# $Full DirPath format is \
\192.168.240.10\oldserver\Backup\MyDocsBackup\backup
my $SubName = &?ROUTINE.name;
my Str $RtnStr = RunCmd "powershell Test-Path $DirPath", True;
$RtnStr = $RtnStr.chomp;
if $CommandLine.debug { print "$SubName: powershell Test-Path
returned <$RtnStr> for <$DirPath>\n\n"; }
if $RtnStr.lc.contains( "true" ) { return True; } else { return
False; }
}
Oh ya, and the above actually works!
Forgive my being crabby. I have been coding on this project
for over a week. It was only suppose to take a day. I have
been CHASING GHOSTS. I am really, really tired. Now I have
to remove all of the IO calls from my code and replace them
with calls to powershell. AAAA HHHH !!!!!! At least I
have finally figured out what was going wrong.
Thank you for the help!
-T
On 4/11/25 12:53 AM, William Michels via perl6-users wrote:
> From Raku's `rename` man-page:
>
> "Note: some renames will always fail, such as when the new name is on a
> different storage device. See also: move."
>
> https://docs.raku.org/routine/rename
<https://docs.raku.org/routine/rename>
>
> HTH, Bill.
>
> PS. If you want Raku code fitting a 'create-backup; unlink-original;
> copy-backup-to-original-location' strategy, look here:
>
> https://unix.stackexchange.com/questions/749558/remove-exact-line-from-
> file-if-present-leave-the-rest-of-lines-error-handling/749581#749581
Hi Bill,
Whilst we all wait for Raku for Windows to get their IO
act together, this is how I handled it. Works 100% of
the time:
Thank you for the heads up.
-T
sub Rename( Str $OldPathName, Str $NewName ) returns Bool is export(
:Rename ) {
# powershell.exe Rename-Item -Path "C:\NtUtil\a.txt" -NewName "b.txt"
# $OldPathName should contain the path unless it is the current
directory;
# $NewName just contain the new name, not the path; Note: this is
different than the raku IO "rename"
my Str $SubName = &?ROUTINE.name;
my Str $RtnStr = RunCmd( "powershell.exe Rename-Item -Path " ~
Q["] ~ $OldPathName ~ Q["] ~ " -NewName " ~ Q["] ~ $NewName ~ Q["], True );
# print "RtnStr = <$RtnStr>\n";
if $RtnStr eq "" { return True; } else { return print "$SubName:
ERROR <" ~ $RtnStr.lines[0] ~ ">\n"; return False; }
}
