I have Winforms insight have one picture box. When I double click, my logic writes (using stream class) a picture and then stores one in the system folder. When I am trying to write, I get an error like "can't access file; it's being processed by another process".
How can I overcome this problem?
Make sure to close your stream after each write.
A few tips:
Restart your machine, see whether it still has the same problem.
Try to disable the previous write in your code, see whether it is the previous writes that locks the file resources.
Does it happen when you write the first or the second time? If it's the second time, you have probably forgotten to dispose or close something. If you have loaded an image from that file, you must dispose the image before you can write to its file, sine an image ownd the stream it was loaded from.
System folder? Trying to overrite a system file (most likely to be write-locked)?
Related
Suppose you are writing a list of names in a file, each name being written in a write command. Why isn't it a good idea to open the file before each writing and close it right after each writing?
Intuitively, I would say that this aproach is a lot more time consuming than writing to a buffer and posteriorly writing to the file. But I'm sure there is a better explanation to that. Can someone enlight me?
Let's sum it up:
Opening and closing a file for every single write operation, when many such operations are planned, is a bad idea because:
It is terribly inefficient.
It requires an extra seek to the end of file in order to append.
It forfeits atomicity, meaning that the file may be renamed, moved, deleted, written to, or locked by someone else between the write operations.
Think of all the possible reasons why fopen (and related) might fail when you call it even once: the file doesn't exist, your account doesn't have permission to access or create it, another program is using the file exclusively, etc.
If you are repeatedly opening and closing the file for every write operation, this chance of failure increases quite a bit.
Also, there is an overhead associated with acquiring and releasing resources (e.g. files). You'd observe it more if you were acquiring and releasing write access to the file every single time you needed to write.
I'm currently having a problem updating the data written on a file in C. I created a function called preview_data() in loop that previews all the files written on INFOS.DAT constantly. I also created a function called update_data() that modifies INFOS.DAT if there's a new data available. I'm using fwrite() and fread() to modify the file.
However, I noticed that the changes made by update_data() is not taking effect. I suspect that this is because INFOS.DAT is being accessed every second by preview_data().
Now with my question, how to restrict a file from being opened if it is being accessed by another process? Are there any way to know it so that I can create a break condition on my program? Thank you.
It may happen if you are using the same file descriptor for opening and closing the file. You can overcome the problem by putting a 'MUTEX' lock on the file descriptor while reading or writing on the file.
Hence, if you are reading the file there will be a lock which will not allow to write in the file simultaneously and vice versa.
NOTE : Please note that you may have to compromise with the performance of the program.
In order to restrict access to a file, we need to lock the file. Locking a file can be done using two ways:
1) flock
2) fcntl
Refer this link:https://gavv.github.io/articles/file-locks/
Is there a way to tell if the contents of the stat/status file for a process has changed, without opening it?
I was thinking you could just check the last-modified time, however the timestamp almost never changes. I coded this using stat(), however it did not return the desired effect (same with ls under the shell.)
It's quite possible I'm looking about this the wrong way. I'm just wanting to be able to constantly probe the stat values of the process, similar to the top command (and no, taking data from top is nowhere near acceptable.)
You can't do this using any normal I/O operations on stat/status because they're not true files.
https://unix.stackexchange.com/questions/90627/notify-of-changes-on-a-file-under-proc explains why you can't work with these files like with regular files.
Why do we need to close a file that we opened? I know the problems like - it can't be accessed by another process if the current process doesn't close it. But why at the end of execution of a process the OS checks whether it is closed and closes it if opened. There must be a reason for that.
When you close a file the buffer is flushed and all you wrote on it it's persisted to the file. If you suddenly exit your program without flush (or close) your FILE * stream, you will probably lose your data.
Two words: Resource exhaustion. File handles, no matter platform, is a limited resource. If a process just opens file and never closes them, it will soon run out of file handles.
A file can certainly be accessed by another process while it is opened by one. Some semantics depend on the operating system. For example, in Unix, two or more processes may open a file concurrently to write. Almost all systems will allow readonly access to multiple processes.
You open a file to connect the byte stream into the process. You close the file to disconnect the two. When you write into the file, the file may not get modified right away due to buffering. That implies that the memory buffer of the file is modified but the change is not immediately reflected into the file on disk. The OS will reflect the changes in disk when it has enough data for performance reason. When you close the file, the OS will flush out the changes into the file on disk.
If you "get" a resource, it is good practice to release it when you have done.
I think it's not a good thing to trust what an O.S. would do when the process end: it might free resources or not. Common O.S. does it: they close files, free allocated memory, …
But if it's not part of the standard of the language you use (e.g. if it implements garbage collectors), then you shouldn't rely on that common behaviour.
Otherwise, the risk is that your application would lock/eat resources on some systems, even if it ended.
In this way it is just a good practise. You are not obliged to close files at the end.
Imagine you'll write a genial but messy method. You'll forget about the caveats and later find out, that this method may be used somewhere else. Then you'll try to use this method maybe in a loop and you'll find out that your programm is unexpectedly crashing. You'll have to go deeper in the code and fix that. So why won't you make the function clean at the beginning?
Do you have something against (or are you afraid of) closing files?
Here is a good explanation: http://www.cs.bu.edu/teaching/c/file-io/intro/
When writing into an output file, the information is hold in a buffer and closing the file is a way to be sure that everything is posted to the file.
I am creating an application that must use the system(const char*) function to do some "heavy lifting", and I need to be able to give the user a rough progress percentage. For example, if the OS is moving files for you, it gives you a progress bar with the amount of data moved and the amount of data to move displayed on the window. I need something like that. How can this be done?
Edit: Basically, I give the user the option to save files in a compressed format. If they do so, it saves normally then runs this code:
char* command = (char*)[[NSString stringWithFormat:#"tar -jcvf %#.tar.bz2 %#", saveurl.path, filename] cStringUsingEncoding:NSUTF8StringEncoding];
system(command);
Sometimes this takes a little while (the app deals with video files), so I want to be able to give them an estimated completion time.
I am creating an application that must use the system(const char*)
function to do some "heavy lifting"
No, it doesn't have to use system() as such. In fact, it shouldn't. There are plenty of other APIs for running subprocesses, almost all of which will be better. In Cocoa, the most obvious better option is NSTask.
In any case, there's nothing that can tell how much progress a subprocess is making except that subprocess itself. If the program you're running doesn't provide a means for reporting progress, there's little hope. Nothing else can even divine what the purpose or goal of the subprocess is, let alone judge how far along it is to meeting that goal.
Even if the program does report progress, you'll need a means to receive that information. system() doesn't allow for that. NSTask does, as would popen() or manually forking and execing the program.
You would need a command line program that has a way of communicating progress information back to your application (or perhaps simply write progress info to a log file that you parse in your cocoa app). Are you sure you really need to do this?
For your edited example, you might consider just putting up some sort of spinner or hourglass type UI indicator to show them that the write is in progress, while allowing them to continue with other work. You can't predict archive creation time, especially when you add compression to it.