4 ms·

This is hardly Linux's fault, nor its responsibility. As far as I know Linux gives you mechanism to lock files and directories, so the compression program you u

This is hardly Linux's fault, nor its responsibility. As far as I know Linux gives you mechanism to lock files and directories, so the compression program you used should have locked the directory by default until it was done or canceled. And if that option was not the default in the program you've used, it could be present as an optional flag. Someone with more knowledge please correct me if I got the above wrong. That being said, the issue with Windows is that it prevents me from deleting a file if it's open in a text editor or any program, which should not be the default in my opinion. A directory gets locked simply because you have explorer open in that path, or a terminal cd'd into that path, which is annoying and counter productive most of the time.

323 4y ago
> so the compression program you used The standard Linux compression programs, zip, gzip, tar, don't lock by default. I don't even think they have such an option.
cesarb 4y ago
> As far as I know Linux gives you mechanism to lock files and directories, so the compression program you used should have locked the directory by default until it was done or canceled. File locking on Linux is advisory, it excludes other processes which try to lock the same region of the same file, but not operations other than locking. Mandatory locks were optional (required a mount option, see https://lwn.net/Articles/667210/ https://lwn.net/Articles/667210/ for details), and were removed in 5.15 (https://lwn.net/Articles/874493/ https://lwn.net/Articles/874493/).
- Bilal_io 4y ago
  Thank you for the links. I did a bit of reading to learn a bit and my understanding of the advisory file locking is that it can be ignored by programs that don't respect it. Is it fair to say that the the shell or gui the user used should have respected the advisory lock? Of course that's assuming the compression program used does attempt to apply file lock, which may not be the case according to another comment.

323 4y ago

> so the compression program you used The standard Linux compression programs, zip, gzip, tar, don't lock by default. I don't even think they have such an option.

cesarb 4y ago

> As far as I know Linux gives you mechanism to lock files and directories, so the compression program you used should have locked the directory by default until it was done or canceled. File locking on Linux is advisory, it excludes other processes which try to lock the same region of the same file, but not operations other than locking. Mandatory locks were optional (required a mount option, see https://lwn.net/Articles/667210/ https://lwn.net/Articles/667210/ for details), and were removed in 5.15 (https://lwn.net/Articles/874493/ https://lwn.net/Articles/874493/).

Bilal_io 4y ago
Thank you for the links. I did a bit of reading to learn a bit and my understanding of the advisory file locking is that it can be ignored by programs that don't respect it. Is it fair to say that the the shell or gui the user used should have respected the advisory lock? Of course that's assuming the compression program used does attempt to apply file lock, which may not be the case according to another comment.