0

I'm trying to implement an in-memory file system using fuse. The rename function accepts 'from' and 'to' parameters.

When I tried doing this on bash, mv file1 file2, it internally calls rename function (I used the -d option to check it).

When i try to rename the function in the GUI, it again calls the rename function.

But if file2 is an already existing file, mv command overwrites it whereas the GUI prevents me from renaming the file. How do I enforce this constraint because internally both these actions call the rename function with no distinction.

Torpedo
  • 171
  • 1
  • 3
  • 10
  • Why do you believe that the behavior with `mv` is any different for your filesystem than any other filesystem? – Ignacio Vazquez-Abrams Nov 28 '13 at 06:06
  • 2
    Afaik the only way to get that behavior is to check if the file exists as a separate operation before even calling `rename`. I'm guessing the GUI you're describing does that. – Joachim Isaksson Nov 28 '13 at 06:15
  • I dont believe that mv is different. My concern is that when I do mv file1 file2, file2 gets overwritten if it already exists. If I do a rename on gui, it prevents me. How do I handle it in my code when internally both of them are calling the rename function. – Torpedo Nov 28 '13 at 06:15
  • Which constraint are you referring to when you say "How do I enforce this constraint"? –  Nov 28 '13 at 06:22
  • As in, if rename has been called by a mv command, I should be able to overwrite the existing file. If it is just a rename done in GUI, I should prohibit it. Afaik, in rename function, there is no way to know who the caller is.. – Torpedo Nov 28 '13 at 06:40
  • GUI behaves as it pleases and the filesystem code has no say in that whatsoever. It implements the filesystem API as documented and that's it. – n. m. could be an AI Nov 28 '13 at 06:42
  • 1
    I think it makes sense. When I tried to rename using the GUI, it didnt call the rename function internally. I checked it using -d option in FUSE. Only mv command is calling rename internally. So my problem is kind of solved. Thanks all. :) – Torpedo Nov 28 '13 at 06:48

1 Answers1

1

The rename function replaces the target file atomically with removal of the old name. This is the whole point of it, and if it doesn't do that correctly, various things would break badly. For applications that want to prevent renaming over top of another file, they have to use the link function (which will fail if the target exists) first, then unlink the old name if link succeeded.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • Or, even simpler, the GUI might just be checking whether the other filename is in use and displaying an error if it is. It's not atomic, sure, but that's unlikely to be significant in a GUI file manager. –  Nov 28 '13 at 07:10
  • @duskwuff: Indeed, I suspect that's the way most broken GUI software works...but it doesn't mean we should condone it. It actually could matter if you have a big copy/move operation going on in one window that has the disk thrashing/swapping badly and interactively rename a file in another window. – R.. GitHub STOP HELPING ICE Nov 28 '13 at 07:20
  • 1
    You can't always use `link()`, though. Not all filesystems support hard links (FAT doesn't, for instance), and some (like HFS+) may have to do a lot of extra work to handle a link/unlink. –  Nov 28 '13 at 07:22
  • I think its similar to what duskwuff has mentioned. The GUI is just checking whether the file name is in use and displaying an error msg there. – Torpedo Nov 28 '13 at 07:23
  • @duskwuff: Interesting point. Is there any workaround for this? – R.. GitHub STOP HELPING ICE Nov 29 '13 at 18:40