You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The apparent source of this behavior is this block of code in coreutils' copy.c, called from mv.c:
/* Here we have two symlinks that are hard-linked together,
and we're not making backups. In this unusual case, simply
returning true would lead to mv calling "rename(A,B)",
which would do nothing and return 0. I.e., A would
not be removed. Hence, the solution is to tell the
caller that all it must do is unlink A and return. */
if (same_link)
{
*unlink_src = true;
*return_now = true;
return true;
}
and this block that actually does the unlink:
if (x->move_mode)
{
if (abandon_move (x, dst_name, &dst_sb)
|| (unlink_src && unlink (src_name) == 0))
{
/* Pretend the rename succeeded, so the caller (mv)
doesn't end up removing the source file. */
if (rename_succeeded)
*rename_succeeded = true;
if (unlink_src && x->verbose)
printf (_("removed %s\n"), quote (src_name));
return true;
}
if (unlink_src)
{
error (0, errno, _("cannot remove %s"), quote (src_name));
return false;
}
}
This behavior is appropriate in normal file systems, but in TagFS, the semantics of the i-number, when the use_ino option is active, don't align with the semantics of unlink as generally understood. Not enabling the the use_ino option can remove this problem, but it also makes it impossible for most utilities to identify a file as the same file at different locations which can cause problems when one attempts to copy a file onto itself at a distinct location.
The text was updated successfully, but these errors were encountered:
The linking branch attempts to address this issue by causing the unlink operation to remove the tag corresponding to the last directory in the path for the unlink rather than completely deleting the file. Additionally, a file is not completely deleted until all tags are removed from the file and then the file is unlinked. Unfortunately, these semantics leave many files in the system which may have been intended for destruction.
The apparent source of this behavior is this block of code in coreutils'
copy.c
, called frommv.c
:and this block that actually does the
unlink
:This behavior is appropriate in normal file systems, but in TagFS, the semantics of the i-number, when the
use_ino
option is active, don't align with the semantics of unlink as generally understood. Not enabling the theuse_ino
option can remove this problem, but it also makes it impossible for most utilities to identify a file as the same file at different locations which can cause problems when one attempts to copy a file onto itself at a distinct location.The text was updated successfully, but these errors were encountered: