-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Working fsck.udf
badly needed
#21
Comments
Hi, that is correct, I am working on it. I have a very little time for that, but it is slowly moving forward. |
Can you please provide some information on the current status of the udf fsck?
|
Hi, I am author of fsck for udf but I have no time to work on it now. There are some issues on ARM platform what was raised later as requirement from @pali plus some other stuff. Overall I think it is safe to try it but I am not sure about production use. There were some nasty issues on large drives so it definitely needs testing and feedback but I am out of time, at least for now. |
@argorain thank you for the prompt answer and for the effort in giving us the beta. I'll give it a try, then, truly hoping that you'll be able to recover work on it soon. I just wanted to make sure that there was nothing holding you back, such as lack of feedback from testers on systems different from yours. |
No problem. Please keep in mind it is really an beta so run it rather on image or copy of your drive rather that live data. And if you encounter anything odd, please let me know. I am not saying I'll work on it anytime soon but always once in a while I am going thru those reports. |
As a matter of encouragement here is an article from 2013 that already states that the world is in the starting blocks for using UDF as USB-key filesystem as soon as an fsck.udf will be working on GNU+Linux :-) |
Sorry to "move the knife in the wound" (it's a french expression) Cheers freind(s). |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Hello @Hussamt @remi75! Independently of which opinion I have on this, I would like if you do not spam this issue. Feel free to move this discussion to other place. I want to have this issue tracker relevant and technically orientated. If you have anything which could help and improve UDF checking tool for Linux, you are free put arguments here. But discussion who and how contribute to Linux world is relevant with topic "udftools does not provide stable checking tool yet". EDIT: I really do not like any moderation, but this discussion is now off-topic. I marked last comments via github button "off-topic", hopefully they are not deleted and just packed. (I really do not want to delete any comments). |
To move discussion back...
@argorain did some testing of MS UDF check disk tool and results were that it broke damaged UDF filesystems even more. @smagnani did another tests and results were that it cannot handle and detect native 4K disks (correctly). So I would not say it is "working" corectly. But maybe something changed... who knows. |
a) well when did he do the tests ?
I have used it again this week with zero issues: a 500G ssd disk
over USB 3.1 ... every-time linux-steam trashes it, I hook it up on tha
windows and it get fixed. it is a fact, fyi: I use linux and windows
since the early 90' ... so trust me please, I have trashed / fixed ALOT
of disks in my life and that with many FSs and OSs.
b) well, since M$ is reading this thread, you are free to file a bug
report with them :)
Cheers and xanax .
Le 07/09/2020 18:40, pali a écrit :
To move discussion back...
> But it is a shame that M$ has a working fsck.udf and not "us" ;)
@argorain [1] did some testing of MS UDF check disk tool and results were that it broke damaged UDF filesystems even more.
@smagnani [2] did another tests and results were that it cannot handle and detect native 4K disks (correctly).
So I would not say it is "working" corectly. But maybe something changed... who knows.
--
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub [3], or unsubscribe [4].
|
Sure. Thank you for the feedback but out of courtesy, shouldn't you also be moderating false information? I was led to believe there was a fsck.udf binary from another vendor that did not truly exist. |
Listen mister man, I Might have made one mistake, I didnt write
"fsck.udf" , instead I wrote fsck.udf ,
Do you understand that ? It is a provocation from you to pretend to not
have understood that , otherwise,
I urge you to change carrier and go to a m$Donald, there they have a
strong policy about trademarks.
Also, If you "do not like moderation" , get out of your office, and go
have a more intelligent chit-chat around the corner about the quality of
the hot-dogs across the street.
Cheers and sleeping-pills
Le 07/09/2020 21:00, Hussam Al-Tayeb a écrit :
> Hello @Hussamt [1] @remi75 [2]! Independently of which opinion I have on this, I would like if you do not spam this issue. Feel free to move this discussion to other place. I want to have this issue tracker relevant and technically orientated. If you have anything which could help and improve UDF checking tool for Linux, you are free put arguments here. But discussion who and how contribute to Linux world is relevant with topic "udftools does not provide stable checking tool yet".
>
> EDIT: I really do not like any moderation, but this discussion is now off-topic. I marked last comments via github button "off-topic", hopefully they are not deleted and just packed. (I really do not want to delete any comments).
Sure. Thank you for the feedback but out of courtesy, shouldn't you also be moderating false information? I was led to believe there was a fsck.udf binary from another vendor that did not truly exist.
Also the regarding the "M$" labeling, shouldn't that be moderated as well? Not all Linux software developers, technicians, and system administrators reflect a toxic view towards developers from a competitive operation system. Some of us who perform technology work at engineering firms for a living try as much as possible to portray a positive, professional, and diplomatic image that shies away from such terminology.
--
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub [3], or unsubscribe [4].
|
Two suggestions for moving the ball forward on a functional fsck:
B. Collect some examples of corruption to determine which are most common and therefore most important to fix. Examples would be hugely helpful, both to udffsck development and regression testing, as well as possibly pointing to driver issues (based on trends and analysis/speculation on how various types of corruption could have occurred). For this I have in mind a program and/or script that would scan a partition and gather up all the blocks with UDF metadata into a tarfile, which could then be used to reconstruct an image of the filesystem (without any file content, of course). |
there was link to udf_test archive, archive was downloaded and looked into, not tried to compile it on Android/termux yet.. |
udf_test is still available to download from moved Philips Parther Area website and seems that registration is not needed anymore. |
@pali there is now fsck_udf from netbsd (also can create udf 2.50 fs on hd) "Newfs_udf and makefs now also support formatting of UDF 2.50 with a metadata partition." I tried to make those (makefs/fsck) compile on Linux (see my repo) but they sadly do not work as intended (some descriptors are off, and fsck can segfault on just created test image) - strangely there is no segfault on termux... |
Hello, any updates on fsck.udf ? |
Hello, not from my side. It is not forgotten but I didn't had time to
finish merging and to be frank, not really will to do that. But hey, maybe
at some point in future I'll get back to it.
Vojtech
pá 26. 4. 2024 v 3:00 odesílatel Henrique ***@***.***> napsal:
… Hello, any updates on fsck.udf ?
—
Reply to this email directly, view it on GitHub
<#21 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABZTSJMVDZWBH5ROXEXQMILY7GRKTAVCNFSM4FN4QPUKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBXHA2DCMZZGI2A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Hello, ok, no problem, but if you don't want to implement it anymore and still think it's important and should be maintained, may I suggest you that you post a public request for help ? This should be in contrast to the recently seen xz backdoor, where the lack of publicity allowed bad actors to hijack the slowly evolving project. |
Fair enough but I am not maintainer though, Pali is. Are you volunteering (wink, wink)? Jokes aside, recovery part of what I wrote is not really good but I still think integrity checking is pretty solid so maybe some refactoring and merging at least that might be worth considering. Odesláno z mého zařízení Galaxy
-------- Původní zpráva --------Od: Henrique ***@***.***> Datum: 26.04.24 16:34 (GMT+01:00) Komu: pali/udftools ***@***.***> Cc: Vojtech Vladyka ***@***.***>, Mention ***@***.***> Předmět: Re: [pali/udftools] Working `fsck.udf` badly needed (#21)
Hello, ok, no problem, but if you don't want to implement it anymore and still think it's important and should be maintained, may I suggest you that you post a public request for help ? This should be in contrast to the recently seen xz backdoor, where the lack of publicity allowed bad actors to hijack the slowly evolving project.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
No, I can't, I have a chronic illness and don't have free time. Less important than immediately finishing it is urgently announcing that help is needed. |
More important |
FYI. when I was working on a UDF-centric product several years ago I did try to make incremental improvements to Vojtech's work. You may find my fork (or at least some of the changesets) useful. https://github.com/smagnani/udftools.git I do use this udffsck to check integrity periodically and to make simple repairs such as closing a LVID left open by a surprise dismount. Unfortunately I too no longer have time to devote to this project. Best Regards, |
To me this seems the one super-duper urgent need for wide usage of the UDF filesystem, a working
fsck
program. Without this and improperly removed USB key results in unrepairable filesystem damage. Worse, damage like that accumulates and over time you end up with a major problem.Personally, I'd rate this as urgent. udftools has template files, they merely need to be filled in...
The text was updated successfully, but these errors were encountered: