Atomicity of renaming a file

[Frédéric SERGENT]

Hello Ricky,

I have a question regarding file renaming atomicity in UFFS.

We are implementing a mechanism (above UFFS:-)) involving the creation of a temporary file, that we have to rename once we are sure of its content.

I would like to know how sure and atomic the renaming of a file is: my understanding is that renaming a file involves a flush of its first block because the info we are changing have to be in the first page of the first block. So, if a reset or a power down occurs while renaming the file, we might be in the middle of copying the content of the first block (i.e. all the pages containing data).

So, my question is: how safe is it to do this? How does UFFS handle that kind of situation: when remounting, is there a risk that the new block might be seen as the proper beginning of the file, and that the data in it might be not totally written and thus, the file corrupted?

Thanks in advance,
Fred

[Ricky Zheng]

Hi Fred,

Renaming a file is atomic, just like modifying any part of the file. Renaming a file does not change file serial number (which is the link between the FILEonly involves flushing a single block, which is safe from any accidental power cuts.

2012/1/11 Frédéric SERGENT <fred.se...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "UFFS" group.
To view this discussion on the web visit https://groups.google.com/d/msg/uffs/-/cxZDWWRY_8wJ.
To post to this group, send email to uf...@googlegroups.com.
To unsubscribe from this group, send email to uffs+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/uffs?hl=en.

[Ricky Zheng]

Hi Fred,

Renaming a file is atomic, just like modifying any part of the file. Renaming a file does not change file serial number (which is the link between the FILE node and the rest of the DATA node), it only flushing a single block, which is safe from any accidental power cuts.

Regards,
Ricky

2012/1/11 Frédéric SERGENT <fred.se...@gmail.com>

[Frédéric SERGENT]

Ok, great! That simplifies our task quite a bit. Thanks Ricky!

Fred

[Frédéric SERGENT]

Hi Ricky,

this calls another question from my side: renaming is atomic, but I think delete is not, right? According to tests I have made, if I get a reset in the middle of a uffs_delete, I get a truncated file. Is this a normal behaviour, or did I do something wrong?

Thanks,

Fred

Le mardi 10 janvier 2012 21:11:12 UTC+1, Ricky Zheng a écrit :

[Ricky Zheng]

Hi Fred,

No, deleting a file is not atomic.

When deleting a file, UFFS chops file block by block from the end of file, until all blocks are been erased. 

I think we can turn this into atomic by reverse the order - erase head block (FILE block) first, and the rest of the file. If interrupted,

the rest of blocks will become 'orphan' and will be erased in next mount.

Will do the change soon.

- Ricky

2012/1/12 Frédéric SERGENT <fred.se...@gmail.com>

To view this discussion on the web visit https://groups.google.com/d/msg/uffs/-/9dsROJ6EtBgJ.

[Frédéric SERGENT]

Ok, that's what I figured.
I think it would actually be a great feature. It would really complete the collection of things that are already atomic in UFFS. In any case, that would be quite helpfull to us! :-)

Thanks,
Fred

Le mercredi 11 janvier 2012 21:29:25 UTC+1, Ricky Zheng a écrit :

Hi Fred,

No, deleting a file is not atomic.

When deleting a file, UFFS chops file block by block from the end of file, until all blocks are been erased. 

I think we can turn this into atomic by reverse the order - erase head block (FILE block) first, and the rest of the file. If interrupted,

the rest of blocks will become 'orphan' and will be erased in next mount.

Will do the change soon.

- Ricky

2012/1/12 Frédéric SERGENT <fred.se...@gmail.com>

Hi Ricky,

this calls another question from my side: renaming is atomic, but I think delete is not, right? According to tests I have made, if I get a reset in the middle of a uffs_delete, I get a truncated file. Is this a normal behaviour, or did I do something wrong?

Thanks,

Fred

Le mardi 10 janvier 2012 21:11:12 UTC+1, Ricky Zheng a écrit :

Hi Fred,

Renaming a file is atomic, just like modifying any part of the file. Renaming a file does not change file serial number (which is the link between the FILE node and the rest of the DATA node), it only flushing a single block, which is safe from any accidental power cuts.

Regards,
Ricky

2012/1/11 Frédéric SERGENT <fred....@gmail.com>

Hello Ricky,

I have a question regarding file renaming atomicity in UFFS.

We are implementing a mechanism (above UFFS:-)) involving the creation of a temporary file, that we have to rename once we are sure of its content.

I would like to know how sure and atomic the renaming of a file is: my understanding is that renaming a file involves a flush of its first block because the info we are changing have to be in the first page of the first block. So, if a reset or a power down occurs while renaming the file, we might be in the middle of copying the content of the first block (i.e. all the pages containing data).

So, my question is: how safe is it to do this? How does UFFS handle that kind of situation: when remounting, is there a risk that the new block might be seen as the proper beginning of the file, and that the data in it might be not totally written and thus, the file corrupted?

Thanks in advance,
Fred

--
You received this message because you are subscribed to the Google Groups "UFFS" group.
To view this discussion on the web visit https://groups.google.com/d/msg/uffs/-/cxZDWWRY_8wJ.

To post to this group, send email to uf...@googlegroups.com.

To unsubscribe from this group, send email to uffs+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/uffs?hl=en.

[Sergei Sharonov]

On Tuesday, January 10, 2012 at 7:34:12 AM UTC-6, Frédéric SERGENT wrote:

...

We are implementing a mechanism (above UFFS:-)) involving the creation of a temporary file, that we have to rename once we are sure of its content....

Pretty standard technique to ensure atomicity of important changes (e.g. password file).

Unfortunately I am running into issue where UFFS refuses to execute rename operation when target exists:

/>mv env.tmp env.txt

fs  : @1860 - new object already exist!

This message can be traced to uffs_fs.c:

if (uffs_OpenObject(new_obj, new_name, oflag) == U_SUCC) {

uffs_CloseObject(new_obj);

uffs_Perror(UFFS_MSG_NOISY, "new object already exist!");

if (err)

*err = UEEXIST;

goto ext;

}

I believe this to be unexpected (and wrong) behavior.

Open Group docs say:

"If the link named by the new argument exists, it shall be removed and old renamed to new. In this case, a link named new shall remain visible to other processes throughout the renaming operation and refer either to the file referred to by new or old before the operation began."

Any help will be much appreciated. Thanks,

Sergei

[Sergei Sharonov]

Ricky,

RE: failure to rename file when target exists. Any chance there is a (reasonably simple) fix for that? Or should I look into implementing a workaround at the application level (arrgh..)? One of the reasons to use filesystem is to avoid dealing with low-level stuff. Would be really nice if UFFS behaved correctly when moving/renaming files. IMHO rename is very useful atomic primitive.

Thanks,

Sergei

[Sergei Sharonov]

On Wednesday, January 11, 2012 at 2:29:25 PM UTC-6, Ricky wrote:

Hi Fred,

No, deleting a file is not atomic.

When deleting a file, UFFS chops file block by block from the end of file, until all blocks are been erased. 

I think we can turn this into atomic by reverse the order - erase head block (FILE block) first, and the rest of the file. If interrupted,

the rest of blocks will become 'orphan' and will be erased in next mount.

Will do the change soon.

I am running uffs ver 01.03.0500 (according to uffs_version.h). Does it have the above fix?

BTW, is that the latest version?

Thanks,

Sergei