11

I think this is related to iCloud Drive in some way, but I have not investigated.


I'm trying to track down an issue with Perl's rename on macOS using the Apple Filesystem (APFS). I've been able to replicate this with perls back to at least 5.12.3 but all of mine are compiled with Apple LLVM version 9.1.0 (clang-902.0.39.1). Those same perls do not have this problem with FAT or HFS+ filesystems. I haven't noticed this problem anywhere else.

  • Run it the first time. I end up with a Changes and a Changes.bak. That's exactly what I expected.

  • Run it again. You end up with Changes and Changes 3 file. There is no Changes.bak. This is odd.

  • Run it again. I end up with a Changes file, Changes.bak, and Changes 3.

  • Run it again. I end up with a Changes file, Changes 3, and Changes 4. Again, there's no Changes.bak.

  • If I remove the print line I can't get this to present ("Doctor, it hurts when I move my arm like this").

  • I re-ordered the file handle opens and closes but that didn't seem to fix anything.

I figure there's something happening at the filesystem level. So I really have two questions:

  • Is this a bug and at what level? Is the rename not guaranteed to finish whatever it needs to do before I start messing with file handles?

  • I want to read the old file and create the new one that inserts some data in the middle. Copy the header, insert the new lines, output all the old line into the new file. I could write to a temp file and move that later, but am I doing anything else stupid?

If you can reproduce this behavior but don't know, leave a comment. Maybe there's something else odd about my system.


my $changes = "Changes";
my $bak     = $changes . ".bak";

rename $changes, $bak or die "Could not backup $changes. $!\n";

open my $in, '<', $bak or die "Could not read old $changes file! $!\n";
open my $out, ">", $changes;

# comment this print line and there's no problem
print {$out} 'Hello';

close $out;
close $in;
HoldOffHunger
  • 18,769
  • 10
  • 104
  • 133
brian d foy
  • 129,424
  • 31
  • 207
  • 592
  • 3
    `rename`(3pl) simply calls `rename`(2). Win32 and VMS override this (as you can see [here](https://perl5.git.perl.org/perl.git?a=search&h=HEAD&st=grep&s=%23define.*rename&sr=1)), but not MacOS as far as I can see. Check the man page for `rename`(2)? – ikegami Jun 11 '18 at 22:37
  • I'd read rename(2) but it was not illuminating. – brian d foy Jun 11 '18 at 23:07
  • That search I linked didn't tell the whole picture. PerlIO adds a layer of indirection, and while I'm missing a few pieces, I don't see anything but Netware and Win32 overriding there. – ikegami Jun 11 '18 at 23:14
  • 1
    Do you get the same behaviour from a C program? – ikegami Jun 11 '18 at 23:14
  • Does not happen on my Mac. – Skeeve Apr 06 '20 at 13:20
  • 1
    Works as expected for me. OSX 10.14.6 and perl 5.18 with apfs filesystem. – Skeeve May 20 '20 at 11:39
  • Make sure your second open worked, it might be failing. `$!` might have a clue even if it succeeded, try printing it after each file operation. – Schwern Aug 23 '20 at 19:26
  • 2
    This is an issue with iCloud Drive and synchronization. I haven't developed a full demonstration yet. – brian d foy Aug 27 '20 at 23:00
  • Maybe you should `unlink($bak)` before the rename. – Bernhard M. Dec 13 '20 at 17:15
  • The name in `$bak` doesn't exist yet. As I said, this is a remote sync issue with iCloud. – brian d foy Dec 14 '20 at 02:04

1 Answers1

1

I know this is an old question, but this might be been related to a bug Apple's filesystem handling had about a year ago. We ran into some problems with the file metadata (mtime?) not getting set correctly in certain situations.

When you run into problems like this with perl, python, node, etc., try doing the same operation in a different language to see if the same behavior obtains. If so, that's likely an OS bug (most of these scripting languages often are thin wrappers around the c libraries anyway).

Cheers.

jjohn
  • 9,708
  • 4
  • 20
  • 21
  • Thanks. After talking the directory out of iCloud Drive (~/Desktop, really), I haven't had this problem. Now it's on a Synology shared volume and the problem hasn't reappeared. – brian d foy Jul 15 '22 at 06:10