0

I have an script that does this:

 rm -rf "$test_dir" && sync && mkdir -p "$test_dir"
 unzip -qq "$zip" -d "$test_dir"
 # compile and run some stuff, diff some files...
 evince "$pdf" 2>/dev/null  # $pdf is a path inside the mentioned folder $test_dir
 echo "[Next]..."
 read
 # then it goes to the next zip, and do the same again.
  • Let's call a zip file A.zip, and the next (in the list of zip files) B.zip.
  • Each zip file comes with two text files, and a pdf.

The problem:

When the extraction folder was already deleted, and re-created, and it is the turn of B.zip, I cat a text file, and open the pdf in evince. Evince shows the correct pdf from B.zip for one or two seconds.

After that, evince reloads the document, and shows the pdf that came from A.zip.

If I go and manually open the pdf again, it is effectively the one that came in A.zip instead of the one in B.zip (so evince is just opening the new file).

If I manually cat the text file again, the content is not the one of the last cat registered in the terminal (the one in B.zip), but the content of the text file of A.zip

Suspicions:

I am suspecting that somehow, the folder itself (or its content) is coming back from deletion.

Fix attempts:

Previously, I deleted the content of "$test_dir", but not the directory itself. The problem showed very often. Then I decided to delete the folder and re-mkdir it. This seemed to solve it. But now I am seeing the problem again.

I tried adding a sync command right after rm -rf so that goes into disk. The problem persists.

I tried sleep for a second after deletion. The problem persists.

What I have checked:

I have seen several similar questions on the web, but all of them involve some other process, docker, or something else. The folder I am using is just a directory in my home. There is no process running anything special on it, except my script ([update] there was one actually, please see the answer)

I have checked, and I am not unzipping anything anywhere else in the script.

8
  • what do you mean by correspond? You mean that the text files are still the old ones? Was it ever the new ones? It shows you the the new files first, but then suddenly you have old files? To break this down, could you try checking the content of the text files and see if and when you get the new content and if and when it changes? Perhaps something in your#some stuff goes on to unzip the old zip as well? Does this also happen when you manually empty your folder and unzip the new file?
    – rudib
    Nov 19, 2020 at 22:04
  • I mean that the new files get in the folder, I can actually cat a text file (as part of the # some stuff, and open the pdf with evince. But after a second or two, evince (I guess detects a change in the file, and) reloads the pdf, showing now the old file. If I go and manually cat the text file, it is not the new file anymore. I will try to come up with a minimum (non) working example. Thanks a lot for your comments and time. I will add some more details to the question.
    – onlycparra
    Nov 19, 2020 at 23:14
  • 1
    One thing you can be pretty much assured of - files don't "come back" from deletion, except maybe if you have rm aliased to something (e.g., something that tries to provide a "recycle bin" type function instead of deleting files outright). It's basically never necessary for a non-admin to run sync for any reason. It is also not necessary to do sleep to wait for a filesystem operation to complete (from a user space perspective) - by the time your unlink() system call returns, the operation is done.
    – patbarron
    Nov 20, 2020 at 0:11
  • What I would try to do is manually track through the operations performed by the switch, line by line, and perform every operation the script would perform. Manually simulate every line of code. You might also consider posting the actual script you're working with (rather than a fragment of pseudocode) if it's small enough.
    – patbarron
    Nov 20, 2020 at 0:14
  • 1
    In addition to the minimal example, you can also try running inotifywait -m -r $test_dir (or the dir above perhaps) in another terminal. This will log all the "file operations" and should show you when something is changed again.
    – rudib
    Nov 20, 2020 at 0:16

1 Answer 1

0

I found the responsible! it is the MegaSync application. It is running in the background, and somehow, while syncing all, it brings back the just deleted files. I close it, and problem solved.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .