Description of problem: In Fedora system, it shows a later Birth time (btime) than Modify time (mtime) for the default directories and files. Version-Release number of selected component (if applicable): coreutils-8.32-12.fc33.x86_64 How reproducible: Always: the issue is observed each time. Steps to Reproduce: 1. Install Fedora 33 Workstation on the computer or use a Live USB. For Live USB this software can be used on any Linux distribution to create bootable Live USB, see Etcher AppImage version. https://github.com/balena-io/etcher/releases/tag/v1.5.115 2. In this case the Live USB was used. 3. Now view the default directories and files with stat command. Sample 1 [liveuser@localhost-live ~]$ stat -f /usr File: "/usr" ID: df2ad9a09adf6cee Namelen: 255 Type: ext2/ext3 Block size: 4096 Fundamental block size: 4096 Blocks: Total: 1918778 Free: 466818 Available: 462722 Inodes: Total: 492480 Free: 332837 [liveuser@localhost-live ~]$ stat /usr File: /usr Size: 4096 Blocks: 8 IO Block: 4096 directory Device: fd00h/64768d Inode: 262720 Links: 12 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:usr_t:s0 Access: 2021-01-24 16:18:39.427741121 -0500 Modify: 2020-10-19 19:36:28.368446712 -0400 Change: 2020-10-19 19:42:56.989412747 -0400 Birth: 2020-10-19 19:42:22.570493050 -0400 Result 1: The directory /usr has later Birth time than Modify time. Modify: 2020-10-19 19:36:28.368446712 Birth: 2020-10-19 19:42:22.570493050 A logical timestamp must behave differently, which means in this case would be so logical. Birth: 2020-10-19 19:36:28.368446712 Modify: 2020-10-19 19:42:22.570493050 4. Here are some more examples e.g a default file from System. [liveuser@localhost-live ~]$ stat '/boot/config-5.8.15-301.fc33.x86_64' File: /boot/config-5.8.15-301.fc33.x86_64 Size: 225592 Blocks: 448 IO Block: 4096 regular file Device: fd00h/64768d Inode: 117 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:boot_t:s0 Access: 2021-01-24 16:28:15.139987781 -0500 Modify: 2020-10-15 13:23:21.000000000 -0400 Change: 2020-10-19 19:42:22.091452414 -0400 Birth: 2020-10-19 19:42:22.090452329 -0400 Actual results: Fedora system sets illogical timestamp behavior for default system directories and files. Expected results: A logical timestamp behaves system-wide in the Fedora system. This must also apply to end user software and other processes. This is how it looks, an example the user creates a new .txt file or directory. This is the definition that was forgotten in GNU/Linux. A file and directory created at 2021-01-24 00:00:00 atime (Access time): 2021-01-24 00:00:00 mtime (Modify time): (Nothing is displayed here, i.e. no symbol or character, it is simply empty.) ctime (Change time): (Nothing is displayed here, i.e. no symbol or character, it is simply empty.) btime (Birth time): 2021-01-24 00:00:00 Note: In this case, mtime and ctime are empty because this would indicate that the contents of the file and directory have not been updated. Note 2: When users use file systems that do not support certain timestamps, such as ctime (change time), then this character is used - (hyphen) This character - (hyphen) means that the file system does not support it or cannot provide the values for other reasons. The advantage of this definition is that it can be seamlessly adopted by file manager (GUI) developers under GNU/Linux without the need to implement any special behavior in the GUI, e.g. for list view columns or properties. Additional info: This problem should be fixed by the end of the year 2021. It would be good if in next Fedora major version is completely fixed. Tested with this Fedora version. [liveuser@localhost-live ~]$ hostnamectl Static hostname: localhost-live Icon name: computer-desktop Chassis: desktop Machine ID: 354430ed81cd4241a4429f442ac5e7dc Boot ID: bb93ee900cb543ecb210d8bb41a08d65 Operating System: Fedora 33 (Workstation Edition) CPE OS Name: cpe:/o:fedoraproject:fedora:33 Kernel: Linux 5.8.15-301.fc33.x86_64 Architecture: x86-64
It seems to work just fine on my test machines: [root@ci-vm-10-0-138-158 ~]# stat /usr/ File: /usr/ Size: 4096 Blocks: 8 IO Block: 4096 directory Device: fc01h/64513d Inode: 131084 Links: 12 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:usr_t:s0 Access: 2021-01-26 11:11:47.246019794 -0500 Modify: 2020-11-11 06:34:18.917000000 -0500 Change: 2020-11-11 06:34:18.917000000 -0500 Birth: 2020-11-11 06:34:15.294000000 -0500 kdudka@f33 ~ % stat /usr File: /usr Size: 100 Blocks: 0 IO Block: 4096 directory Device: 20h/32d Inode: 1915 Links: 1 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:usr_t:s0 Access: 2021-01-26 18:20:21.369969951 +0100 Modify: 2020-11-02 11:52:28.924578654 +0100 Change: 2020-11-02 11:52:28.924578654 +0100 Birth: 2019-07-15 18:07:21.840684095 +0200 Are you sure that your system clock has always been set properly?
Yes system clock is all correct in BIOS, always on current time. I used this original Fedora 33 (Workstation) iso file. https://download.fedoraproject.org/pub/fedora/linux/releases/33/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-33-1.2.iso SHA256 (Fedora-Workstation-Live-x86_64-33-1.2.iso) = 582a825d564e2682334ac893c9160667c7f4578c0c8045a25ea534af7c13334b To be on the safe side I did not use Live USB anymore, but installed Fedora 33 (Workstation) directly on my computer and used gnome-boxes-3.38.0-1.fc33.x86_64. All run offline on my computer, no network connection established or anything, fully tested offline/locally. Here the stat command from the virtual machine: [liveuser@localhost-live ~]$ stat /usr File: /usr Size: 4096 Blocks: 8 IO Block: 4096 directory Device: fd00h/64768d Inode: 262720 Links: 12 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:usr_t:s0 Access: 2021-01-26 21:19:42.151170527 -0500 Modify: 2020-10-19 19:36:28.368446712 -0400 Change: 2020-10-19 19:42:56.989412747 -0400 Birth: 2020-10-19 19:42:22.570493050 -0400
I tried to install Fedora from the ISO mentioned in comment #2 and there was indeed mtime behind btime on /usr: $ stat /usr File: /usr Size: 100 Blocks: 0 IO Block: 4096 directory Device: 22h/34d Inode: 275 Links: 1 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:usr_t:s0 Access: 2021-01-27 13:48:35.789127591 +0100 Modify: 2020-10-20 01:36:28.368446712 +0200 Change: 2021-01-27 13:35:05.600854340 +0100 Birth: 2021-01-27 13:35:03.052811318 +0100 The following command has fixed it: $ sudo yum reinstall filesystem $ stat /usr File: /usr Size: 100 Blocks: 0 IO Block: 4096 directory Device: 22h/34d Inode: 275 Links: 1 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:usr_t:s0 Access: 2020-07-27 20:22:10.000000000 +0200 Modify: 2021-01-27 13:54:35.291740671 +0100 Change: 2021-01-27 13:54:35.291740671 +0100 Birth: 2021-01-27 13:35:03.052811318 +0100 I do not think that coreutils does anything wrong here. The issue must be specific to the way how Fedora is installed. I am switching this bug to anaconda for further investigation.
I'm not 100% sure, but after a cursory search this seems a reasonable explanation: We copy stuff from Live OS with rsync. I think it does not care about btime by default, so it will be written as the real time you installed. And rsync -t, as we do, will make sure to keep mtime, which will be in the past, when the files were copied onto the original image. Or something along these lines. Code references: https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/modules/payloads/base/installation.py#L57 https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/payload/live/payload_base.py#L108 No --crtimes on -N to be seen there, seems to confirm the theory above.
Tested with anaconda-34.24.9-1.fc34.x86_64 Hash: SHA256 # Fedora-Workstation-Live-x86_64-34-1.2.iso: 2007367680 bytes SHA256 (Fedora-Workstation-Live-x86_64-34-1.2.iso) = 865c4457dd066d3074c35a8847c8dac1380667c96a4f6d74526324dba14f1b5c I can also confirm the problem in current Fedora 34 version. $ stat '/run/media/liveuser/Anaconda/boot' File: /run/media/liveuser/Anaconda/boot Size: 4096 Blocks: 8 IO Block: 4096 directory Device: fd01h/64769d Inode: 17 Links: 6 Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:boot_t:s0 Access: 2021-04-23 07:02:00.738512439 -0400 Modify: 2021-04-23 07:00:49.322221586 -0400 Change: 2021-04-23 07:02:02.748689509 -0400 Birth: 2021-04-23 07:02:02.615677793 -0400 $ stat '/run/media/liveuser/Anaconda/home' File: /run/media/liveuser/Anaconda/home Size: 4096 Blocks: 8 IO Block: 4096 directory Device: fd01h/64769d Inode: 119 Links: 2 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:home_root_t:s0 Access: 2021-04-23 07:01:51.081661795 -0400 Modify: 2021-01-26 01:05:10.000000000 -0500 Change: 2021-04-23 07:02:02.749689598 -0400 Birth: 2021-04-23 07:02:02.748689509 -0400 $ stat /usr File: /usr Size: 4096 Blocks: 8 IO Block: 4096 directory Device: fd00h/64768d Inode: 133 Links: 12 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:usr_t:s0 Access: 2021-05-07 16:00:51.845813373 -0400 Modify: 2021-04-23 06:56:31.181486095 -0400 Change: 2021-04-23 07:02:38.266818198 -0400 Birth: 2021-04-23 07:02:02.753689950 -0400 You can always see that btime (Birth) is always after mtime (Modify) and this is an illogical behavior for an operating system. btime must always be before mtime. > We copy stuff from Live OS with rsync. I think it does not care about btime by default, so it will be written as the real time you installed. And rsync -t, as we do, will make sure to keep mtime, which will be in the past, when the files were copied onto the original image. Or something along these lines. It does not seem to be an anaconda problem because rsync --crtimes rsync: This rsync does not support --crtimes (-N) rsync error: syntax or usage error (code 1) at main.c(1746) [client=3.2.3] All processes and software in Fedora must preserve btime. By default, Fedora can only use software and processes that have this behavior, everything else must be removed because of illogical behavior. This means anaconda must also be changed. This means it is a kernel problem. Linux does not fully support btime. Can you send this report to the Linux kernel developers so that it can be fixed. 1. These are the tasks for the Linux kernel to fully support btime. This is the standard behavior. - preserve btime when copying files and directories to the destination (this works for cabled transmissions and wireless transmissions) - setting the btime to any value in an existing file and directory (very important for rsync to make --crtimes command work) - if mtime, ctime and atime is set before btime, does not work there is an error message - if btime sets after mtime, ctime and atime, does not work there is an error message The logic must always be that only the Linux kernel can use btime and btime must always be before mtime, ctime and atime. The advantage is currently Linux is not yet popular among users so this problem must be fixed immediately. I think this task is very important.
(In reply to Marek Svoboda from comment #5) > btime must always be before mtime. Where is this requirement specified? As I understand it, atime/mtime of an existing file can be arbitrarily changed from user-space, which is not possible for btime/ctime.
> Where is this requirement specified? A real example is this report page. In the overview you can see Reported: 2021-01-24 19:13 UTC Modified: 2021-05-08 21:08 UTC Reported is for example another name for btime. Other websites, like gitlab take the word -> "Created". There are also enough everyday examples in real life. An example is my mother, she has some photos and many documents and diaries from 18th century and 19th century and mostly it says when it was, so the birth hour. As you can see it is something normal and Fedora uses illogical behavior as an operating system. I think operating systems should adapt more to the real world, because there are so many great examples in the real world. My mother for example is older than many Unix and Linux systems, I want to say that we should not forget the past. Why is this important to me? For me, for example, btime is far more important than the last mtime. If I have written a text with a lot of work and heart blood, then I would like to know later, when that was and yet not whether I have found maybe 3 years later a spelling mistake and corrected ... This is also a problem in the standard text editor software in Fedora 34. gedit-40.0-3.fc34.x86_64 If I create a .txt file with gedit and 1 minute later modify the same .txt file, then btime has the same time as mtime. > As I understand it, atime/mtime of an existing file can be arbitrarily changed from user-space, which is not possible for btime/ctime. Exactly, I have not found a way to change the behavior for btime/ctime in Fedora 34. Therefore, the behavior should be changed, as I already wrote in comment 5, what tasks should be done. The Linux kernel should set btime/ctime logically so that software does not create illogical timestamps. Perhaps an additional solution is also important, the atime and mtime must not be changed from the user space more, but it works only with the Linux kernel. What is your idea? btime and ctime can be changed from user space? If yes it is also possible, but there is then a big administration problem.
(In reply to Marek Svoboda from comment #7) > > Where is this requirement specified? > > A real example is this report page. I was asking about specification though. Could you please provide any link to the specification that requires btime to always be lower than mtime? > Therefore, the behavior should be changed, as I already wrote in comment 5, > what tasks should be done. The Linux kernel should set btime/ctime logically > so that software does not create illogical timestamps. Perhaps an additional > solution is also important, the atime and mtime must not be changed from the > user space more, but it works only with the Linux kernel. Sorry, I am afraid I do not follow you. > What is your idea? My idea is that Linux kernel works as expected. If anaconda preserves the original mtime of installed files, there is no way to guarantee that mtime will always be after btime. So there is nothing to fix, as I understand it. > btime and ctime can be changed from user space? I do not think so although I am not an expert in this area.
> I was asking about specification though. Could you please provide any link to the specification that requires btime to always be lower than mtime? No specification is generally available for btime. The only thing I have found is this. Usually there are atime, ctime, mtime. https://pubs.opengroup.org/onlinepubs/009696699/basedefs/xbd_chap04.html#tag_04_07 https://pubs.opengroup.org/onlinepubs/007904875/functions/open.html Further applies: If O_CREAT is set and the file did not previously exist, upon successful completion, open() shall mark for update the st_atime, st_ctime, and st_mtime fields of the file and the st_ctime and st_mtime fields of the parent directory. This means that ctime = mtime = atime applies when creating the file. So if btime exists, then btime <= or => atime, ctime, mtime can be. The btime value can be set freely. > My idea is that Linux kernel works as expected. > If anaconda preserves the original mtime of installed files, there is no way to guarantee that mtime will always be after btime. So there is nothing to fix, as I understand it. btime is not specified so the value can be set freely. That means btime may be changed in user space. The current Linux kernel behavior is a bug, because it does not allow to change btime freely. The Linux kernel developers have added btime support since Linux kernel 4.11 (year 2017). But did not add a way to change the btime value. If the Linux kernel developers don't want it, then they must specify btime.
The mentioned specification does not mention btime at all. There might be good reasons why there is no syscall to change btime arbitrarily. I would suggest to ask upstream kernel developers directly.
> The mentioned specification does not mention btime at all. I said that btime does not specify. Then it means that btime is independent and can set this value at will. > There might be good reasons why there is no syscall to change btime arbitrarily. If there is the reason then it must be specific. If there is no specification, btime can be set to any value.
Nope. It just means that you have not found any specification that would support your claim.
> Nope. It just means that you have not found any specification that would > support your claim. The same is true for the current behavior. The current behavior is that the Linux kernel developers have already specified btime and according to this report and my tests with the default text editor in Fedora 34 btime => mtime. This way doesn't have to be the only true way because as you can see there are use cases that want to set btime differently, in my case I want logical behavior. I don't want btime to be updated every time the file is changed. Also, rsync and backup programs cannot restore the original btime value. The mistake was made by the Linux kernel developers to add btime with this specification btime => mtime. But there is no specification that the Linux kernel must behave this way, so the current behavior is a bug. I have researched and neither IEEE, POSIX and others mention or specify btime in any way. This basically means that the btime value is free to be set and this must not be restricted by the Linux kernel developers. If the Linux kernel developers think that btime should be specified, then they must also make it a common specification with the POSIX people or the like. It would be good if an upstream kernel developer can give an answer here, can you help? To enlighten what should be the next steps. I have 2 direct suggestions. 1) Add expected behavior, i.e. in the next upstream kernel release, btime can be set to any value because btime was not specified. No specification means there is no reason and this value can be set freely. Basically no restrictions. 2) btime will be removed from the upstream kernel until a specification exists in general. A proposal should be sent to POSIX (or its successor) to specify btime together.
Marek, if you keep using words like "mistake" or "bug" for any behavior that does not match your personal expectations, it is better not to contact upstream kernel developers. They are busy with fixing real bugs.
Based on this bit from comment 5, I'm reassigning to rsync. If --crtime was supported, Anaconda could just use it. > It does not seem to be an anaconda problem because > rsync --crtimes > rsync: This rsync does not support --crtimes (-N) Marek, I think the request - set btime when installing Fedora - is a good one, and I like it. However, you have used a lot of potentially strong words in ways that can be easily understood to imply a strong opinion. It could be better to *not* add more of these words, so that the request is judged on technical merit and viability, and not disagreement with perception of your opinions...
(In reply to Kamil Dudka from comment #14) > Marek, if you keep using words like "mistake" or "bug" for any behavior that > does not match your personal expectations, it is better not to contact > upstream kernel developers. They are busy with fixing real bugs. I try to contribute to fix the problem for all interested. Yes that is the mistake, because the current behavior was specified btime => mtime by the Linux kernel developers but there is no specification for btime or can you show me a specification for btime in general that it has to be like that? Why can't btime be like this btime <= => mtime as already said, so btime can be set to any value, this would be in principle the expected behavior, then the problems here would be solved. The user or developer can do what he wants with btime, developers can create software that can be like this btime => mtime or btime <= mtime. Backup programs can restore btime value etc... Besides, it is not only my personal expectations but I explained in the beginning what is the cause and it cannot be solved from user space area because the problem is the Linux kernel. Basically, the Linux kernel developers whether intentionally or not have restricted user space software and there is no way to change it. If there is the reason, then it must be specified, just like for atime, mtime and ctime, as already said. You don't need to be afraid of the upstream kernel developers. Therefore it would be good if you could help and forward the report to the upstream kernel developers or that an kernel developer from RedHat can propose a satisfactory solution taking into account all points to make the next step.
(In reply to Vladimír Slávik from comment #15) > Based on this bit from comment 5, I'm reassigning to rsync. If --crtime was > supported, Anaconda could just use it. > > > It does not seem to be an anaconda problem because > > rsync --crtimes > > rsync: This rsync does not support --crtimes (-N) > > Marek, I think the request - set btime when installing Fedora - is a good > one, and I like it. However, you have used a lot of potentially strong words > in ways that can be easily understood to imply a strong opinion. It could be > better to *not* add more of these words, so that the request is judged on > technical merit and viability, and not disagreement with perception of your > opinions... Kamil wanted to know a specification and I only explained at the beginning why I prefer the real examples. Later he really wanted a specification and because of his wish I just explained that there is no specification. If there is none, in principle users and developers (user space area) can do with btime what they can. After some tests I also noticed that btime was already specified in the background by the Linux kernel developers, but I found no specification that it must be so. Currently there are 2 different interests it seems that the Linux kernel developers only want to prefer btime => mtime, for whatever reason. But others prefer btime <= mtime and probably there are others who also prefer btime => mtime. The solution I can think of now that works immediately is to set btime to some value. Then developers can add in backup programs an on/off option if they want to restore btime value for their files and directories.
(In reply to Vladimír Slávik from comment #15) > If --crtime was supported, Anaconda could just use it. Yes, in theory, but rsync could hardly implement such an option if there is no interface for it in the Linux kernel. I was not involved in developing or discussing the kernel side myself but a quick google search gives me this, which I am afraid is the ultimate answer: https://linuxlists.cc/l/5/linux-ext4/t/2979599/(rfc_patch_0_6)_allow_setting_file_birth_time_with_utimensat()#post2980290
(In reply to Kamil Dudka from comment #18) > (In reply to Vladimír Slávik from comment #15) > > If --crtime was supported, Anaconda could just use it. > > Yes, in theory, but rsync could hardly implement such an option if there is > no interface for it in the Linux kernel. I was not involved in developing > or discussing the kernel side myself but a quick google search gives me > this, which I am afraid is the ultimate answer: > > > https://linuxlists.cc/l/5/linux-ext4/t/2979599/ > (rfc_patch_0_6)_allow_setting_file_birth_time_with_utimensat()#post2980290 This is not the ultimate answer. It is about setting btime value (<= =>) for the user space and the reasons why it was not added are personal interests of some Linux filesystem developers. A specification that it must be so was not mentioned and according to the author other non-Linux operating systems do it differently and allow btime to be set to any value regardless of which filesystem is used. The Linux filesystem developers have not discussed the current btime => mtime behavior there because it is a different topic there. That is the difference. This report here was originally more about how btime <= mtime should always be. In summary, this report is a discussion for the kernel area and no longer for anaconda or rsync. whether btime => mtime should always be or btime <= mtime. This was not discussed. Therefore, the report here should be forwarded to the kernel developers what their opinion is.
I think it is obvious that kernel cannot guarantee btime <= mtime when mtime can be easily set to the past from user-space while original btime is preserved. Please consider using extended attributes for your use case, as it was suggested in the discussion that comment #19 refers to.
(In reply to Kamil Dudka from comment #20) > I think it is obvious that kernel cannot guarantee btime <= mtime when mtime > can be easily set to the past from user-space while original btime is > preserved. This is not obvious because you are not a kernel developer. You said yourself that you are not an expert in this area. Therefore it is good if a kernel developer could give an answer. The current behavior may or may not be intentional. There seems to be no discussion, so is this report here a change of behavior or just look if the current behavior is intentional or not. There are some ideas mtime can no longer be changed from the user space or if mtime is set before btime, then btime has the same value as mtime. That would guarantee for btime <= mtime. The same question also applies can btime => mtime also be guaranteed? > Please consider using extended attributes for your use case, as > it was suggested in the discussion that comment #19 refers to. Your suggestion (comment #18) is not really a solution, just because some Linux filesystem developers need certain metadata from the filesystem, this cannot automatically mean that they are allowed to determine everything. You can see for yourself in the report that there are other Linux file system developers who see it differently. Fact is there is no specification that it has to be like that. Realistically, kernel developers have a lot of power and can very quickly restrict user space software. In principle, everyone who uses Linux is very dependent on the kernel developers.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.